Release 2.15.4 breaks semver

[binford2k]

The latest release drops support for Ruby 2.3. That's fine, but it was marked as 2.15.4 which breaks semver. That means that projects that use cri are now broken. For example, https://github.com/puppetlabs/r10k/blob/a84c7072e007042cd7926c298445b6c1a1c0141c/r10k.gemspec#L21-L26

This release should be pulled and rereleased as 2.16.0.

[denisdefreyne]

Hi Ben,

Ruby 2.3 is unmaintained: it does not even receive security updates anymore. For this reason, Cri no longer supports Ruby 2.3 either.

Dropping support for unsupported Ruby versions does not require a major release. Quoting the Semantic Versioning 2.0.0 specification:

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

It believe it is a stretch to call dropping support for Ruby 2.3 a change to the public API. Even if you do considered this change a change to the public API, I find it hard to justify that dropping support for an already-unsupported unsupported version of Ruby is a backwards-incompatible change.

[denisdefreyne]

I’ll leave this issue open for now because I’d like to hear your thoughts.

Ideally, you’d migrate off of Ruby 2.3 (and 2.4) as soon as possible.

[denisdefreyne]

Hmm, I just realised that the version of Ruby that ships with the most recent version of macOS is also 2.3 — and this presumably won’t be upgraded until the next major version of macOS. Given the historical release frequency of macOS, that might take until the end of the year, and possibly into 2020 if given some time for adoption.

I don’t know what the situation is on the main Linux distributions, but I hope they do better.

[scotje]

I will preface this by saying you are of course free to version your software however you see fit. :)

I think this is an unfortunate situation where semver is underspecified. Personally, my definition of "backwards incompatible" is something like "it worked before the upgrade and doesn't work after", which unfortunately a runtime environment removal breaks. The spirit of semver as I see it is that .z upgrades should be safe and unsurprising.

RedHat still ships Ruby 2.0.0 in RHEL7 FWIW, they just backport the security fixes as they come out. I believe Ubuntu 16.04 LTS (not EOL until April 2021) ships Ruby 2.3.0.

The real shame is that Rubygems still doesn't correctly avoid incompatible versions when it is resolving dependencies. If it did then all these issues would pretty much go away.

[denisdefreyne]

I’ve reverted the removal of Ruby 2.3 support and released a new version, 2.15.5, which will work as expected on Ruby 2.3.

I’m leaving this issue open for now, because we need to figure out what the support strategy is. Questions to ask:

• When is it OK to drop Ruby 2.3 support?
• Does it make sense to support older versions of Ruby (2.2, 2.1, …) as well? If so, for how long?

[scotje]

@ddfreyne Personally I think it's a reasonable compromise to drop support for older Rubies as part of a minor version bump.

For our use cases, we encounter this kind of thing enough that we generally declare dependencies like this in our gemspec:

  spec.add_runtime_dependency 'cri', ' >= 2.10.1', '< 2.16.0'

Removing support as part of a minor version bump at least preserves the opportunity to resolve critical bugs and release an updated patch release for the older tree. For example:

• 2.15.5 is released with Ruby 2.3 support
• 2.16.0 is released which drops support for Ruby 2.3.x
• Downstream consumers who need to maintain Ruby 2.3.x compatibility can pin to "2.15.x"
• Important bug or security flaw discovered in master
• Official fix released in 2.16.1
• Downsteam consumers can branch code from last tag of 2.15.x release, backport fix, and submit the patch back up to you for release of an official 2.15.6

To me this ends up being a nice balance where the package can continue to move forward and adopt new language features but it's also possible for downstream consumers to make reasonable dependency management decisions and it's not too difficult to facilitate patch releases of older versions when necessary.

[denisdefreyne]

I’m OK with having Cri be supported out of the box on

• Ubuntu LTS
• the last two major macOS releases

… which means that I’ll keep Ruby 2.3 support around for another two years, give or take.

Having a formally-defined compatibility would still be good, though.

[denisdefreyne]

I’d like to add that it is fairly easy for Cri to keep on supporting Ruby 2.3, primarily because it has no dependencies. For a larger project with dependencies (e.g. Nanoc) I found it considerably harder to retain compatibility.

[denisdefreyne]

I’ve opened #95, a PR that adds a compatibility policy. Would love your feedback!

[denisdefreyne]

The compatibility policy, added in #95, is now in place.

I believe it will provide the necessary guarantees for r10k, but if not, let’s continue the discussion!