Create a maintenance branch for each major Rails version we want to support. #238

Closed
aslakhellesoy opened this Issue Feb 27, 2013 · 8 comments

Comments

Projects
None yet
3 participants
Owner

aslakhellesoy commented Feb 27, 2013

Currently that means:

  • rails-2.3.x
  • master (implicitly rails-3.2.x)
  • rails-4

Once Rails 4 is released, we should have those branches:

  • rails-2.3.x
  • rails-3.2.x (former master)
  • master (former rails-4)

For example, PR #213 should be applied against the rails-2.3.x branch.

This was referenced Feb 27, 2013

Contributor

urbanautomaton commented Feb 27, 2013

Just checking in here following the discussion in #237 about testing against multiple gemfiles - looks like the appraisal/multi-gemfile approach could definitely help here, too. And again, I'm happy to submit a PR once I get a better idea what you're after.

With the branching approach, how do you envisage managing releases from the different branches? E.g. if #213 were applied to the rails-2.3.x branch, would that then be released as a discrete version of the cucumber-rails gem? Or would you expect users wanting ongoing support of old rails versions to use those specific branches as a git dependency in their Gemfiles?

Owner

aslakhellesoy commented Feb 27, 2013

how do you envisage managing releases from the different branches

by checking the branch out locally and then run rake release

would that then be released as a discrete version of the cucumber-rails gem

Ideally yes. According to our wiki the latest rails-2 compatible release is cucumber-rails-0.3.2, so a new release for rails-2 should be cucumber-rails-0.3.2.1.

To recap:

Rails 2

Development happens on the rails-2.3.x branch, which we should create off from the v0.3.2 tag.
New releases will be called 0.3.2.X.

Rails 3 and Rails 4

If we can make Cucumber-Rails' tests work with both Rails 3 and 4 from the master branch we don't need a separate branch. If this turns out to be a problem in the future we'll create a rails-3.2.x maintenance branch off from the latest release that works with Rails 3.

Contributor

urbanautomaton commented Feb 27, 2013

Ah right, I follow - thanks. Will get to work on a PR on master to test against rails 3.x and 4.

@urbanautomaton urbanautomaton added a commit to urbanautomaton/cucumber-rails that referenced this issue Mar 1, 2013

@urbanautomaton urbanautomaton Multiple-gemfile testing and travis configuration
The test suite now runs (and passes!) against the latest versions of:

* Rails 3.0, 3.1 and 3.2
* Capybara 1.1 and 2.0

The default test task is unchanged, and runs only against Rails 3.2. See
the README for details of running all (or selected) tests.

Addresses issues #237 and #238.
28ee021
Member

Kosmas commented Mar 13, 2013

Created new branch rails-2.3.x based on release 0.3.2

Member

Kosmas commented Mar 13, 2013

Since we are going to use this branch for rails 2.3.x should we remove the references to rails 3?

Owner

aslakhellesoy commented Mar 13, 2013

@Kosmas in both comments and code? That sounds wise.

Member

Kosmas commented Mar 13, 2013

@aslakhellesoy I was thinking about the comments and documentation initially, but yes eventually in code would make sense too.

Member

Kosmas commented Aug 23, 2013

Closing as we have versions all versions working now.

Kosmas closed this Aug 23, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment