Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
aslakhellesoy opened this Issue · 8 comments

3 participants

@aslakhellesoy

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

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

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

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

@urbanautomaton urbanautomaton referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@urbanautomaton urbanautomaton referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@urbanautomaton urbanautomaton referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@urbanautomaton urbanautomaton referenced this issue from a commit in urbanautomaton/cucumber-rails
@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
@Kosmas
Owner

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

@Kosmas
Owner

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

@aslakhellesoy

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

@Kosmas
Owner

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

@Kosmas
Owner

Closing as we have versions all versions working now.

@Kosmas Kosmas closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.