Remove support for Ruby 1.8.x

[denisdefreyne]

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.

• Set minimum Ruby version
• Update style to 1.9 (using Rubocop’s autocorrect)
• Remove OrderedHash
• Remove Date#freeze hack
• Remove Enumerable#group_by
• Remove 1.8.x from Travis CI configuration
• Remove 1.9+ requirements from Gemfile

[denisdefreyne]

+1s please — CC @nanoc/contributors

[mpapis]

a lot of changes 👍 assuming the tests pass

[denisdefreyne]

Will write an e-mail to the mailing list to explain the end of Ruby 1.8.7 support.

[bobthecow]

I'm increasingly of the opinion that 1.8.x should be "deprecated and untested" but not explicitly removed until 4.x. Let people open pull requests to fix things in 3.x if they come across them, but don't worry ourselves about it otherwise.

[mpapis]

we can not support 1.8.7 without major changes - see #510 & #513, even if someone would like to work on it - it would introduce changes that might be hard to accept (like rewriting Piper)

[denisdefreyne]

@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. Piper is tricky.

[mpapis]

there is possibility to use combination of popen4 gem and JRuby function ... but it would be still bigger changes in name of supporting unmaintained ruby version

[denisdefreyne]

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:

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

About dependencies:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. [..]

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.

[denisdefreyne]

(I’d like to continue this discussion in this thread rather than on Twitter, because the conversation there became very difficult to follow.)

[mpapis]

http://guides.rubygems.org/specification-reference/#required_ruby_version= - can we yank the past versions that do not work with 1.8.7 and release new 3.6 and 3.7 that have required_ruby_version specified?

[denisdefreyne]

Some points that I’d like some opinions about:

• Should 1.8.6 and 1.8.7 support be retained even if that means not supporting other platforms, such as JRuby? Piper is tricky to support on both.
• How much effort do we want to put in supporting 1.8.x?

[denisdefreyne]

@mpapis We cannot replace those releases (not even with yanking), so that won’t help.

[mpapis]

1.8.6 should not be supported - this ruby version is long dead

we can yank published gem versions starting from 3.6.9 and provide new releases for 3.6 and 3.7 that have the required_ruby_version set to >=1.9.3 (1.9.2 is also problematic) - this way gme install nanoc on 1.8.7 would install 3.6.8

we could branch from 3.6.8 to provide bug/security fixes on 1.8.7 and continue versioning it as 3.6.8.x

[denisdefreyne]

1.8.6 should not be supported - this ruby version is long dead

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.

we can yank published gem versions starting from 3.6.9 and provide new releases for 3.6 and 3.7 that have the required_ruby_version set to >=1.9.3 (1.9.2 is also problematic) - this way gme install nanoc on 1.8.7 would install 3.6.8

That could work.

we could branch from 3.6.8 to provide bug/security fixes on 1.8.7 and continue versioning it as 3.6.8.x

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.

[mpapis]

assuming some identifiable version of nanoc 3.x supports 1.8.6 - then we can do the same thing as for 1.8.7

as for the branching - every rule has exceptions, we could limit the maintenance branches to security fixes and only then allow the 3.6.8.x version scheme - maybe never, but rubygems supports

[denisdefreyne]

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.

[mpapis]

hmm, I was half way to fix the 1.8.7 support ... would feel less as wasted time if I would finish it

[denisdefreyne]

@mpapis It’s OK to just leave it the way it is. It’s not going to be easy to finish adding full 1.8.6 compatibility.