search

cucumber / aruba

Test command-line applications with Cucumber-Ruby, RSpec or Minitest.
MIT License
949 stars 163 forks source link

Improve branch-model #363

Closed ghost closed 7 years ago

ghost commented 8 years ago

Summary

Improve branch-model to make contributing easier.

Expected Behavior

Taken from here.

it's mostly bugfixes and new features (like Docker), so there shouldn't be any conflicts. If that's an issue, it's best to switch master to 1.x, branch off 0.14 for backporting, and just focus on releasing 1.x ASAP. It's no problem to then work on 2.x a month from now - no one will complain because of "too many major releases". Aruba is complex, so learning is expected. And if learning is reflected in "multiple major releases", that's just an indication of how much learning (or rework) was needed, nothing else. I'm guessing it's actually more useful to just skip to 2.x (master - without releasing), branch off 1.x as unreleased as "work in progress" (too keep the branches). E.g. I'm (as a contributor) only interested in master and not backward compatibility or deprecations - so it makes no sense to add an artificial "burden" on master. You can always work on a "transition release" - but only if there's a genuine need in the community. Master branch should be optimized for quickly accepting PRs. (If PRs don't have priority over other work, contributing feels very discouraging - as if there's a ton of "bureaucracy"). It doesn't make sense to expect contributors to make backports of their own fixes (that they don't need themselves).

Current Behavior

It takes a long time to release a major release.

Possible Solution

Release faster.

e2 commented 8 years ago

:+1:

e2 commented 8 years ago

Release 0.1.0 was in ... 2010. So Aruba hasn't reach 1.x in more than 6 years...

e2 commented 8 years ago

I have a suggestion for this.

Symptoms

Cause

Master branch is expected to be available for 0.14.x patches.

Root cause

1.x development hasn't even BEGUN!

Why is this the root cause?

1.x has diverged too much from 0.14.x - and yet master STILL hasn't switched to 1.x.

If work on 1.x had begun, master would effectively be 1.x

Why the "root cause" a problem?

Because the default merge target of pull requests is master. If the master branch is currently "used as" 0.14.x, which means that, the way things are set up ...

... it's harder for people to contribute to 1.x because it's officially still an "experimental branch".

Why is the root cause still present?

Because no decision has been made to "officially" start working on 1.x. 1.x is still an "experiment" and not a development branch.

What's the philosophical problem within the root cause?

The irony is that 0.14.x is treated (and used) as production code, while 1.x is too "experimental".

Which means users are forced to use an "experimental API" (since 1.x. wasn't released yet) ... while contributors are forced to "maintain compatibility with 0.14.x", making master effectively just a "backporting branch" for 0.14.x

What's the suggested fix?

Simple: if master is stable enough to still be called "0.14.x" ...

  1. All PRs and branches should be reviewed - if there's anything that belongs in 0.14.x, it should be merged to master ASAP (!!!).
  2. The branch "0-14-stable" should be created from tag @v0.14.1
  3. As soon as 0-14-stable is created, again, review all PRs and branches and merge them into master ASAP (to avoid merge conflicts with new PRs).
  4. ALL deprecated and outdated code (including Ruby 1.8.7 support !!!) should be PURGED from the codebase on master IMMEDIATELY. Dropping Ruby 1.9 support is a fantastic idea. Drop EVERY possible line of code that isn't ESSENTIAL! (Adding things back is easy if needed). It's also a good point to COMPLETELY DROP WHOLE FEATURES. Anything that has even a slight "hint" of being removed in the future should be GONE as soon as possible. This should include RVM support and EVERYTHING that would land in other gems. This is a one-in-a-release-cycle chance to do this kind of "spring cleanup".
  5. Now "active development" can happen on master until 1.x release.
  6. If previous features need to be added back, you'll have 1.1.x, 1.2.x, ... etc.

Result

You'll have only 2 branches: 0-14-stable and master (for 1.x work currently).

And then, master can stay as 1.x until work "starts" on 2.x (by creating a 1-0-stable branch).

What about Ruby 1.8.7 ?

Backward compatibility has a price.

The only question is: who should pay? The people who can't afford to "upgrade" or contributors who want to add feature and fix things?

There are 2 options:

  1. People interested in Ruby 1.8.7 support should "pay the price" of backporting and selecting the 0.14.x branch for pull requests. (Or requesting backports specifically).
  2. Contributors should be 100% "free" from any cost associated with Ruby 1.8.7.

This way, Ruby 1.8.7 can still stay in .travis.yml on the 0-14-stable branch, while it can be removed from master. People who need the backports should either cherry-pick commits from master or manually diff with master and prepare PRs for backports. Yes, it isn't convenient. But it's "their fault" for sticking to 1.8.7, even though it's a dangerous security risk they're only perpetuation. If they're setting up servers on 1.8.7, and Ruby 1.8.7 exploits are used against them, the whole Ruby community will get a bad rep. Not to mention - Ruby community growth is slowed down every time someone "needs 1.8.7 support". It doesn't make sense for the rest of the community to pay the price of backporting.

People using Ruby 1.8.7 should be forced to decide: either move to Ruby 2.x - or pay for 100% of the overhead of not switching to 2.x. That's only fair - especially given all the effort out there to create 2.x and make everything seamlessly compatible with it.

And just the same: not releasing Aruba 1.x is unfair to all the users who want some sense of certainty and guarantees about Aruba in the future.

0.14.x is a "scary" version to have on master.

And that's the case right now.

ghost commented 8 years ago

@e2 Sorry, saw your comment just now. I got back to this last night and had a similar idea.

@mattwynne @aslakhellesoy @tooky @brasmusson What do you think about this for the "aruba" project? Is this something which could work for cucumbers as well?

Reason

Idea

Pros

Cons

e2 commented 8 years ago

This might help decide on a future-forward branching policy:

There's only one thing you need for backward compatibility: to allow for it. This just means a minor version bump, so that any backports can be done by locking to that minor and patch-level upgrades.

E.g. (fictional example):

0.10.0 supports Ruby >= 1.8.7 1.0.0 support only Ruby 2.3 (drops support for Ruby 2.2, 2.1, 2.0, 1.9.3, 1.8.7) 1.1.0 supports Ruby 2.2 through backporting 1.2.0 supports Ruby 2.1 through backporting 1.3.0 drops support for Ruby 2.1 (no security updates) 1.4.0 drops support for Ruby 2.2 1.5.0 reintroduces support for Ruby 2.1 and Ruby 2.2 1.6.0 drops support for Ruby <= 2.3.0 (e.g. 2.3.1 is ok due to bug in Ruby 2.3.0)

Notice that a user who needs Ruby 2.1 can use any of these versions: 0.10.0 (maybe) 1.2.0 (supported) 1.5.0 (supported again - but the codebase is clean, so codebase pollution is minimal)

And, if needed, any backward-compatibility can be reintroduced in any minor version by a patch-level release.

This is because "Aruba API compatibility" and "Ruby language compatibility" are 2 separate concepts. "Ruby language compatibility" is already versioned by Ruby - so there's no need to version it within Aruba too. (Which is why a major version bump isn't needed at all).

For more info, see:

https://gist.github.com/e2/ac32569852cbd31f7da637500174d907

maxmeyer commented 8 years ago

@e2 I think we're going to drop 1.8.7 and 1.9.2 on 1.0.0, but not 1.9.3. I would like to see rspec using aruba 1.0.0 and they're going to drop ruby 1.8.7 with the upcomming major release.

e2 commented 8 years ago

TL;DR - you should read, because there's an elephant in the room that no one wants to talk about: Aruba already doesn't support Ruby 1.8.7.

@maxmeyer - it's not like 1.9.3 support will "disappear" from earlier versions. There's simply no point in "dragging" it through the next major releases. RSpec != Aruba. You can always backport fixes even for 1.8.7 in the 0.x branch. It's not like something "magical" will happen when 1.x is released. What is the benefit of RSpec switching to Aruba 1.x anyway?

RSpec is a special case, because is the foundation of fixing bad code bases. The same isn't true of Aruba.

What's the purpose of supporting a buggy and insecure 1.9.3? And what's the point of having 1.x support it when 0.x already supports it? It's not like anything "magical" will happen for 1.9.3 users either.

What's the actual use case here? What if RSpec doesn't upgrade to Aruba 1.x over the next 3 years? (Quite likely if there are no benefits).

Forgive me for being observant and analytical here: there's all this "talk" about "supporting Ruby 1.8.7/1.9.3", but it's all nothing but talk. It's like with politics - lots of declarations and promises, but not practical ideas or execution. Communication for the sake of communication.

Every single argument for supporting Ruby < 2.2 just falls flat on it's face given enough insights and thinking.

E.g. Aruba uses childprocess, right? And you're promising Ruby 1.8.7 support as of today, right? Well, check out which versions they're actually testing on Travis:

https://github.com/jarib/childprocess/blob/dfb2f289eb5e2fdd8d28e24768754394c0d324d1/.travis.yml

And since which version:

https://github.com/jarib/childprocess/blob/dfb2f289eb5e2fdd8d28e24768754394c0d324d1/lib/childprocess/version.rb

And check out which version of Ruby Aruba is declared to support: https://rubygems.org/gems/aruba (0.5.6).

This means Aruba's "assumption" for Ruby 1.8.7 support is based on an RUBY-1.8.7-UNTESTED-VERSION of childprocess.

This means, childprocess can add a single Ruby 1.9.3 feature and ... Aruba will break on Ruby 1.8.7 systems.

So Ruby 1.8.7 support with Aruba is just an illusion waiting to be smashed. This means you should at least lock to childprocess 0.5.8.

And that's not all:

Check out the cucumber gem's gemspec:

https://github.com/cucumber/cucumber-ruby/commit/8dca3e8002d0de62dc08900c770ce4801bc6f4e0#diff-a5408eb4836f6778abfa5db16aea2f7aR14

Yes, you can't install it on Ruby 1.8.7 since Cucumber 2.0. And does Aruba 0.14.1 lock to a Ruby 1.8.7 version?

No: https://rubygems.org/gems/aruba : cucumber >= 1.3.19

I know this is unintentional, but it doesn't make sense to almost "religiously" defend Ruby 1.8.7 support when it comes to contributions, and yet drop the ball when it comes to keeping that "important promise for users".

You can't build trust if you have double standards like that. Either you need to release Aruba 0.14.2 so that it's dependencies are locked to versions tested and installable on Ruby 1.8.7 ... or ... you have to "let go" of the illusion of "supporting Ruby 1.8.7".

Because currently, the "Ruby 1.8.7 must be supported!" only restricts contributors. All because "Aruba works on Travis on Ruby 1.8.7" doesn't mean it's dependencies (as specified currently) do.

Either you care about Ruby 1.8.7 users or you don't.

One more thing to notice: nobody cares that the Ruby 1.8.7 support is an illusion. Except maintainers I guess.

That's why maintainers really have to put lots of thoughts into their decisions. Or not make useless restrictions in the first place.

P.S. I'm being as pragmatic as a I can here. This includes talking about human behavior - including my own.

brasmusson commented 8 years ago

Have a branch "still" (following the naming convention of libreoffice) for last released version of gem

Cucucmber v2.0.0 was released March 27, 2015 and Cucumber v1.3.20 was released June 19, 2015, so I do not think you want a branch for "last released version of gem", but maybe you want branches for older major versions of the gem.

The only reason to have an additional branch than master, is IMHO if you want to be able to accept PR for something else than the next release, that is be able to accept a PR for aruba v0.14.1 while the master branch is for aruba v1.x. In case that it will take time to be able to make an aruba v1.0.0, a branch for v0.x is probably necessary (for a long time during the development of Cucumber v2, there was a v1.3.x-bugfix branch, and several releases were made from it). Otherwise I think that the branch to be able to patch older releases can be made on demand from the tag of the release to be patched.

mvz commented 7 years ago

The 'master' branch is now the branch for release 1.0.0. There is also a 'still' branch for 0.14, so this has basically been done. I personally would like to see a more descriptive name than 'still', but that's a different issue.