New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for Ruby 1.8.x #517

Merged
merged 5 commits into from Jan 4, 2015

Conversation

Projects
None yet
3 participants
@ddfreyne
Member

ddfreyne commented Jan 4, 2015

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

@ddfreyne ddfreyne added to review and removed status:wip 🔧 labels Jan 4, 2015

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

+1s please — CC @nanoc/contributors

Member

ddfreyne commented Jan 4, 2015

+1s please — CC @nanoc/contributors

@ddfreyne ddfreyne modified the milestone: 3.7.5 Jan 4, 2015

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

a lot of changes 👍 assuming the tests pass

Member

mpapis commented Jan 4, 2015

a lot of changes 👍 assuming the tests pass

@ddfreyne ddfreyne removed the to review label Jan 4, 2015

ddfreyne added a commit that referenced this pull request Jan 4, 2015

@ddfreyne ddfreyne merged commit bfd9fa4 into release-3.7.x Jan 4, 2015

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@ddfreyne ddfreyne deleted the remove-1.8.x-support branch Jan 4, 2015

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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

Member

ddfreyne commented Jan 4, 2015

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

ddfreyne added a commit that referenced this pull request Jan 4, 2015

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Jan 4, 2015

Member

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.

Member

bobthecow commented Jan 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

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)

Member

mpapis commented Jan 4, 2015

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)

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

@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.

Member

ddfreyne commented Jan 4, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

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

Member

mpapis commented Jan 4, 2015

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

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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.

Member

ddfreyne commented Jan 4, 2015

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.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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

Member

ddfreyne commented Jan 4, 2015

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

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

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?

Member

mpapis commented Jan 4, 2015

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?

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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?
Member

ddfreyne commented Jan 4, 2015

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?
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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

Member

ddfreyne commented Jan 4, 2015

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

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

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

Member

mpapis commented Jan 4, 2015

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

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 4, 2015

Member

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.

Member

ddfreyne commented Jan 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 4, 2015

Member

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

Member

mpapis commented Jan 4, 2015

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

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 6, 2015

Member

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.

Member

ddfreyne commented Jan 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Jan 6, 2015

Member

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

Member

mpapis commented Jan 6, 2015

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

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 7, 2015

Member

@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.

Member

ddfreyne commented Jan 7, 2015

@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.

ddfreyne added a commit that referenced this pull request Jan 11, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment