Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

@aslakhellesoy
Copy link
Contributor

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
@urbanautomaton
Copy link

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?

@aslakhellesoy
Copy link
Contributor Author

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.

@urbanautomaton
Copy link

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

urbanautomaton pushed a commit to urbanautomaton/cucumber-rails that referenced this issue Mar 1, 2013
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 cucumber#237 and cucumber#238.
@Kosmas
Copy link
Member

Kosmas commented Mar 13, 2013

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

@Kosmas
Copy link
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?

@aslakhellesoy
Copy link
Contributor Author

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

@Kosmas
Copy link
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.

@Kosmas
Copy link
Member

Kosmas commented Aug 23, 2013

Closing as we have versions all versions working now.

@Kosmas Kosmas closed this as completed Aug 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants