v2.2 has a breaking change in a minor version

[ljharb]

We use webmock, ~> 2.0, and maintain support for ruby 1.9.

However, v2.2 dropped ruby 1.9 support - incorrectly, in a minor version.

It would be appropriate to release a 2.x release that is ruby 1.9-compatible, since it's probably way too late to unpublish all of the versions 2.2+.

[bblimke]

@ljharb when you say that 2.2 dropped support in a minor version, what version do you mean exactly?

2.2 is ruby 1.9.3 compatible

2.3 drops support for ruby 1.9.3

Out of curiosity, any reason to still use 1.9 these days?

[ljharb]

@bblimke https://travis-ci.org/airbnb/hypernova-ruby/jobs/182172552 the gemspec says it requires ruby 2.0 or higher.

Yes, our company still uses 1.9, so all our software needs to work on it. Not everyone can upgrade quickly.

[ljharb]

Additionally, dropping support for ruby 1.9.3 is a breaking change and should be semver-major - ie, 2.3 should have been 3.0.

[bblimke]

@ljharb thanks for the complete information.

I'm sorry to hear this change has caused you problems. I understand your point and understand the problem too.

I'd bee keen on fixing this, adding one more 2.3.2 release to fix that and then releasing 3.0 version.

I'm not sure that releasing 3.0 would be a correct decision though. I have spent some time researching this subject, before making a decision whether to go with 2.3 or 3.0 version.

If you look at semver, it enforces a major version change if there are backwards incompatible API changes (https://github.com/mojombo/semver/blob/master/semver.md or http://guides.rubygems.org/patterns/#semantic-versioning). We do not have backwards incompatible API changes in 2.x versions. If I was to upgrade to 3.x, people who have version ~2.0 defined in their Gemfile would not see new releases when upgrading day to day. This includes patch releases, since I'd not have maintained 2.x line anymore.

People are much less keen on upgrading to a major release, since it usually means backwards incompatible changes. In this case, there are no API changes and it does not affect anyone but 1.9 users.

I also took into account that Ruby 1.9.3 had EOL 2 years ago and is not supported anymore, ever with security patches.

In addition, Ruby is just a third party dependency, same as amy third party gems that WebMock depends on or works with. One can't expect a major release every time some third party dependency changes. The main reason for this change was incompatible signature of methods in Net::HTTP in Ruby 2.4 and 1.9. For the same reason I don't make a major release every time of one of the http client libraries supported by WebMock changes.

You will notice that many other Ruby gems have dropped 1.9 support in their minor versions as well, for the same reason - no backwards incompatible API changes.

I find the subject quite ambiguous though, since semver doesn't explicitly define how to deal with dependencies.

You can read more about the problem here: https://github.com/mojombo/semver/issues/148

I'm always open to suggestions and should you give me good enough arguments that minor version is explicitly wrong and why major is correct, I'll be keen to release one more 2.2 version, Ruby 1.9.3 compatible and then release a new 3.0 version.

[bblimke]

Please note that minimum Ruby version is a definition and defined in ruby_version_required declaration in the Gemspec. I can see you are using a 2 year old Bundler 1.7.6, which doesn't support ruby_version_required. If you have used newer bundler, it would have correctly resolved the latest compatible webmock to latest version 2.2.x

[ljharb]

In my experience, a breaking change is any intentional change that results in any previous user of that major line not having things work the same without a code change. In other words, platform/;anguage requirements are just as much a part of the public API as the method signatures and observable behavior. Whether that breaking change comes from gem code, or dependency code, or subdependency code, should be irrelevant - as the consumer of webmock, it only matters that all my webmock code that worked on any release of major version X, work on every later release of major version X without a code change. So yes, if a dependency changes in a breaking way, one can certainly expect a major release if that breaking change ends up exposed to the user - one great way to prevent that problem, as a gem author, is fully encapsulating your use of dependencies such that you do any necessary runtime detection or recovery, so that your users don't have to know or think about the underlying implementation (you probably already are doing this).

As for people being hesitant to upgrade to v3 - indeed, that's why patch releases should be backported to previous major lines whenever possible, but also why consumers should be striving to upgrade dependency versions as much as possible, by using semver ranges and tools that report available updates. The most important thing is not to ensure people upgrade - it's to ensure nobody's working code breaks in a new way.

Your comment about bundler is helpful, thanks - I'll look into upgrading it, since that might be a sufficient workaround. That said, if bundler 1.7.6 worked on 2.0 for ruby 1.9, then it needs to work for every single 2.x.

The Ruby community indeed doesn't have a stellar record with complying with semver, but as a package author myself, I'd hope that we'd all want to hold ourselves to a higher standard then "everybody else is doing it" :-)

Thanks for your consideration!

[bblimke]

I'm still not convinced whether dropping support for Ruby 1.9.3 breaks semver specification,

It's a good enough reason that it causes issues to you and possibly other dev teams.

Version 2.3.2 restored support for Ruby 1.9.3.

[ljharb]

Thank you! ❤

[bblimke]

@ljharb thank you!