Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove support for Ruby 1.8.x #517
Ruby 1.8.x has reached end-of-life, and supporting it is a pain. This PR removes 1.8.x support and uses some 1.9.x-isms.
Also see #513 for a discussion on the motivation for removing Ruby 1.8.x support.
Jan 4, 2015
1 check passed
@bobthecow 1.8.x was deprecated and untested. The reason why all this is happening is because a Ruby 1.8.x incompatibility was reported. Fixing 1.8.x support is not easy, since there’s a bunch of 1.9.3+-only dependencies.
@mpapis Yup, I fear we’ll have to choose between either 1.8.x support or JRuby support.
Does the backwards compatibility constraint truly also apply to end-of-life’d software?
The question is whether or not we want to add compatibility to a version that is not supported anymore, is used by almost nobody, and should not be used anymore at all; the answer to that question is a pretty clear “no” to me.
The precise wording of the Semantic Versioning specification does not imply that the major version number should be bumped when a dependency changes. About the major version number, it says the following:
There’s some more interesting discussion on my Twitter account going on (read the entire conversations).
One point brought up by @sferik is that there’s no need to shy away from major version bumps. My concern here, though, is that any backwards-incompatible change to a dependency of nanoc (such as #502) would require a major version bump, and we’d be bumping the major version of nanoc very frequently. Any change to nanoc that restores compatibility with a newer version of a dependency would mean a new major version. This would not be manageable even if all dependencies used semantic versioning, which they do not.
The fact that nanoc does not have explicit dependencies makes this even harder. (I suppose this is another good reason for splitting every nanoc plugin into its own independently versioned repository.)
nanoc exposes the APIs of dependencies (for example, in filters). This makes filters easy to use, but does that mean that the API of the dependency is part of the nanoc API itself? I would say no; nanoc is merely a proxy.
I would like to bump the major version of nanoc only if there is a backwards-incompatible change to the nanoc API itself.
http://guides.rubygems.org/specification-reference/#required_ruby_version= - can we yank the past versions that do not work with
we can yank published gem versions starting from
we could branch from
nanoc supported 1.8.6 in 3.x, so if we can drop 1.8.6 support, we can also drop 1.8.7 support. Supporting 1.8.7 but not 1.8.6 makes no sense.
That could work.
Firstly, I do not want to do 1.8.x-specific work on nanoc; secondly, the 3.6.8.x format would break semantic versioning.
assuming some identifiable version of nanoc 3.x supports 1.8.6 - then we can do the same thing as for
as for the branching - every rule has exceptions, we could limit the maintenance branches to security fixes and only then allow the
It feels strange to yank a whole bunch of revisions simply because they don’t have an explicit Ruby version (and they should theoretically all be 1.8.6+-compatible).
I’m more and more inclined to follow @bobthecow’s idea of treating the current 1.8.x incompatibility as a bug, and accepting PRs to fix this. I believe we should not be actively working on fixing this ourselves though.