Dropping ruby 1.9 and 2.0 support in a minor version breaks semver

[Richard Macklin]

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:

Gem::InstallError: nokogiri requires Ruby version >= 2.1.0.
An error occurred while installing nokogiri (1.7.0), and Bundler cannot continue.
Make sure that `gem install nokogiri -v '1.7.0'` succeeds before bundling.

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 at bundle 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.

[Matthew Draper]

This question addresses whether SemVer allows a dependency bump in a compatible release (emphasis mine):

Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality.

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 ruby line in your Gemfile. I believe there's also an intention to teach it similar logic even without an explicit version.

(I have no knowledge, and make no claim, as to whether Nokogiri intends to follow SemVer at all.)

[Mike Dalessio]

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:

1. Ruby 2.0 and earlier are out of support life. If your travis build is broken, then you're using an insecure/buggy/unsupported version of Ruby. Please stop doing that as soon as you can!
2. Nokogiri does not claim to follow SemVer. We've simply had too many complex non-backwards-compatible changes related to libxml2 over the years to even come close to claiming this. We'd have to be at something like version 37 by now.
3. As @matthewd suggests, SemVer is subject to interpretation on this point (although, IANAL, so what do I know?). Even if Nokogiri was following SemVer (which actually is a goal of mine), I'm still not sure this would have been an inappropriate decision.
4. This topic ("release 1.7.0 deprecating Ruby 1.9.x support for all platforms") was discussed as early as August 2015 on nokogiri-talk, and at no point then or since has anyone on the list suggested that removing support for EOLed Rubies required a major version bump. It was a non-issue for anyone who was paying attention.

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.