-
-
Notifications
You must be signed in to change notification settings - Fork 900
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
Dropping ruby 1.9 and 2.0 support in a minor version breaks semver #1568
Comments
- upcoming version will be 1.7.0 - note ruby 2.4.0 deprecation warning fixes
This question addresses whether SemVer allows a dependency bump in a compatible release (emphasis mine):
Increasing the minimum version of a dependency, just like adding a new dependency, is not a breaking/major change. It's also not a change that has any reason to be communicated via the version number -- if nothing else, just because there is already a much better mechanism (the actual dependency list) to address it. Rubygems and Bundler manage the Ruby version dependency a little differently than they do inter-gem deps, but that's an implementation detail in those client tools. Given a recent (1.13.x, I think?) Bundler, it will resolve to a set of gems compatible with the ruby version configured with a (I have no knowledge, and make no claim, as to whether Nokogiri intends to follow SemVer at all.) |
Hi, thanks for asking this question. I'm going to be brief only because I lack the time right now for a more thoughtful response. A few things to consider:
If you have a genuine interest in helping nokogiri-core make support decisions, I'd ask that you join and proactively participate in the nokogiri-talk mailing list, rather than reactively ask for an explanation after-the-fact. Sorry if this decision was unexpected or inconvenient, but please do upgrade to a more modern Ruby if this problem bit you. |
What problems are you experiencing?
Nokogiri 1.7.0 was released last night (c5e8e12). It contains commit 8487038 which removes support for ruby versions 1.9 and 2.0. This removal should happen in a major version since it is a backwards incompatible change. In fact, it looks like this was originally planned for a major version bump to 2.0.0, but this was changed to a minor version bump to 1.7.0 in 7f8b7b2. Why was that?
By making this a minor version bump, any lenient dependency on a minor version of nokogiri ~> 1.x now resolves to 1.7.0. This means that any Travis build using ruby 1.9 or 2.0 for projects with a ~> 1.x (direct or transitive) dependency on nokogiri will fail at the
bundle install
step with:For example, see this build log: https://travis-ci.org/teamcapybara/capybara/jobs/187031001
To get Travis back to a passing state, you can add a hacky restriction on
nokogiri < 1.7.0
like they did in teamcapybara/capybara@d785efb#diff-7e45bd0f108a6eaf30ab6af3c3e5a86eR14. However, this will only fix future builds; all older commits cannot be rebuilt because they will fail atbundle install
. Also, while capybara has a direct dependency on nokogiri, many other projects only have it as a distant transitive dependency (e.g. via railties -> actionpack -> rails-dom-testing -> nokogiri), so adding the< 1.7.0
restriction in these projects is a leaky abstraction.So, I'd like to ask: why did 7f8b7b2 change the planned release version from a new major version (2.0.0) to a new minor version (1.7.0), given that the removal of ruby 1.9 and 2.0 is a breaking change? Is there any way you'd reconsider this decision?
Thanks for your work on nokogiri and for taking the time to read this.
The text was updated successfully, but these errors were encountered: