Release 1.3.1 #237
Release 1.3.1 #237
Conversation
| @@ -1,3 +1,9 @@ | |||
| ## [v1.3.0](https://github.com/cucumber/cucumber-rails/compare/v1.3.0...v1.3.1) | |||
|
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. |
|
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 ( Any thoughts on this? |
|
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. |
|
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:
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 Capybara I think probably is worth multiple tests due to the breaking changes mentioned earlier. I would probably follow the above example and specify 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. 😄 |
|
@urbanautomaton those are great tips! We should look into this for #238 as well |
…to release-1.3.1 Conflicts: Gemfile
|
@urbanautomaton would you like to submit a PR with your modifications please? |
|
Yep, sure. I'll try to get testing against different rails versions working at the same time. |
|
On 27 Feb 2013, at 11:13, Simon Coffey [email protected] wrote:
|
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.
|
I believe that #240 covers this one so closing it. |
Upgraded all gems in gemspec