Release 1.3.1 #237

Closed
wants to merge 8 commits into from

4 participants

@Kosmas
Cucumber member

Upgraded all gems in gemspec

Kosmas Chatz... added some commits Feb 26, 2013
@aslakhellesoy aslakhellesoy and 1 other commented on an outdated diff Feb 27, 2013
@@ -1,3 +1,9 @@
+## [v1.3.0](https://github.com/cucumber/cucumber-rails/compare/v1.3.0...v1.3.1)
@aslakhellesoy
Cucumber member

Copy paste error

@Kosmas
Cucumber member
Kosmas added a note Feb 27, 2013

Sorry Aslak.
Fixed now.

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

Apologies for butting in, but is there a particular reason for specifying the very latest version of every dependency? Bumping dependency versions in a patch release could cause significant problems for end users who might have their versions of these dependencies locked for <%= reasons %>.

In particular, I notice that rake has been bumped up over a major version boundary, and one which contains several breaking changes.

@aslakhellesoy
Cucumber member

It was my suggestion to do this. I understand it might be too aggressive for some. We could revert the version upgrade, but we'd still be running our tests against the latest versions (>=), so we don't really know if things work with the lower bound versions.

Any thoughts on this?

@Kosmas
Cucumber member

There was no particular reason for upgrading to all the latest releases of the dependencies, apart from the task of 'upgrading all gems to latest version'.

If there another way of upgrading, which is probably more conservative, and there are suggestions, we can change it back to other versions.

Kosmas Chatz... added some commits Feb 26, 2013
@urbanautomaton

My strong opinion is that gems should be as permissive as possible in the requirements they place on their dependencies. However I happily acknowledge that this is informed by my job as maintainer of an application with a lot of ageing dependencies, and not a maintainer of any significant library.

This only really applies to the runtime dependencies, not the development dependencies, so my previous mention of rake is irrelevant. The cucumber dependency it's pretty obviously okay to bump 😄, leaving Nokogiri and Capybara. Nokogiri only increases its patch version, but again it would be my personal preference not to make users upgrade unless there's a specific reason for it (e.g. a known bug in 1.5.0 that affects this gem, fixed in 1.5.x).

Capybara however is bumped over a major version boundary, and again one that contains significant breaking changes. I would be quite surprised to find my test suite broken by upgrading a rails integration gem from 1.3.0 => 1.3.1.

On testing, Travis supports testing against multiple gemfiles, and my colleague @joecorcoran has pointed me to the appraisal gem, which makes it easy to generate gemfiles varying on key dependencies.

His strategy for testing his judge gem is as follows:

  1. In the gemspec, specify `gem rails, "~> 3.1"
  2. Use appraisal to generate gemfiles with the latest patch version (at the time of release) of rails 3 for each supported minor version (so currently 3.1.8 and 3.2.9)
  3. Tell travis to test against both gemfiles.

In this instance we're worried about Nokogiri and Capybara. I think testing multiple versions of Nokogiri is probably overkill as it's a stable gem and you're already specifying the latest minor version. As a cucumber-rails user I reckon I'd consider the gem to have done right by me if it specified gem "nokogiri", ">= 1.5.0" and was tested against "1.5.x at the time of release".

Capybara I think probably is worth multiple tests due to the breaking changes mentioned earlier. I would probably follow the above example and specify gem "capybara", ">= 1.1.2" while testing against gemfiles with 1.1.2 and 2.0.3.

I realise this is a) more initial work and b) more maintenance overhead, however. If it's an approach you'd be interested in taking then I'd be happy to submit a PR making the necessary modifications.

Anyway, thanks for listening. 😄

@aslakhellesoy
Cucumber member

@urbanautomaton those are great tips! We should look into this for #238 as well

Kosmas Chatzimichalis Merge branch 'release-1.3.1' of github.com:cucumber/cucumber-rails in…
…to release-1.3.1

Conflicts:
	Gemfile
62431b6
@Kosmas
Cucumber member

@urbanautomaton would you like to submit a PR with your modifications please?

@urbanautomaton

Yep, sure. I'll try to get testing against different rails versions working at the same time.

@mattwynne
Cucumber member
@urbanautomaton urbanautomaton added a commit to urbanautomaton/cucumber-rails that referenced this pull request 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
@Kosmas
Cucumber member

I believe that #240 covers this one so closing it.
Let me know if that's not the case.

@Kosmas Kosmas closed this Mar 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment