Remove support for Ruby 2.0.x #4381

Closed
parkr opened this Issue Jan 20, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@parkr
Member

parkr commented Jan 20, 2016

Ruby 2.0.x is presently in maintenance mode. Support for it will end on February 24, 2016. Once it's EOL'd, we should stop supporting it. I'm thinking Jekyll v3.2.

We should document this on the website under "Requirements" and enforce in the gemspec.

/cc @jekyll/core

@parkr parkr added the Discussion label Jan 20, 2016

@parkr parkr added this to the 3.2 milestone Jan 20, 2016

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Jan 20, 2016

Member

Is removing support for a ruby version a backwards incompatible change according to SemVer? I know one of the reasons cited for Rails going to 5.0 instead of 4.3 was because they wanted to remove compatibility with older Ruby versions.

Since we can enforce this in the gemspec and rubygems and bundler, it's probably a moot point, but I figured I'd ask.

Member

mattr- commented Jan 20, 2016

Is removing support for a ruby version a backwards incompatible change according to SemVer? I know one of the reasons cited for Rails going to 5.0 instead of 4.3 was because they wanted to remove compatibility with older Ruby versions.

Since we can enforce this in the gemspec and rubygems and bundler, it's probably a moot point, but I figured I'd ask.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jan 20, 2016

Member

Is removing support for a ruby version a backwards incompatible change according to SemVer?

That was a concern of mine. I don't think the spec says anything about it. I feel like dropping 1.9 support was a bigger thing than dropping 2.0, because Ruby 1.9 and Ruby 2.0 weren't necessarily compatible (thus making it difficult to upgrade) but 2.0 and 2.1 are supposed to be compatible so the upgrade path should be easier for users.

Notably, this breaks support for native installation on Mac, which, I believe, runs 2.0.

Member

parkr commented Jan 20, 2016

Is removing support for a ruby version a backwards incompatible change according to SemVer?

That was a concern of mine. I don't think the spec says anything about it. I feel like dropping 1.9 support was a bigger thing than dropping 2.0, because Ruby 1.9 and Ruby 2.0 weren't necessarily compatible (thus making it difficult to upgrade) but 2.0 and 2.1 are supposed to be compatible so the upgrade path should be easier for users.

Notably, this breaks support for native installation on Mac, which, I believe, runs 2.0.

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Jan 20, 2016

Member

Notably, this breaks support for native installation on Mac, which, I believe, runs 2.0.

It does break native installation on Mac. I'm on El Capitan and still only have 2.0.0p645. The work laptop has Yosemite which is 2.0.0p481 😞

Member

mattr- commented Jan 20, 2016

Notably, this breaks support for native installation on Mac, which, I believe, runs 2.0.

It does break native installation on Mac. I'm on El Capitan and still only have 2.0.0p645. The work laptop has Yosemite which is 2.0.0p481 😞

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jan 21, 2016

Contributor

The only notable incompability (which isn't even listed on the Ruby site) is keywords. We can enforce them in 2.0... we can in 2.1. This is what prompted me to get angry at 2.0.... because when building Pathutil to encapsulate safety and speed into Pathname for Jekyll and Docker-Template and my apps, I couldn't enforce keywords, I had to loosen my restrictions and add some logic I wouldn't normally add.

I think the drop should only be superficial until 4.0 though, don't test for it, don't care about it, but if there is a problem take it on a case-by-case until 4.0 and announce the change as official.

Contributor

envygeeks commented Jan 21, 2016

The only notable incompability (which isn't even listed on the Ruby site) is keywords. We can enforce them in 2.0... we can in 2.1. This is what prompted me to get angry at 2.0.... because when building Pathutil to encapsulate safety and speed into Pathname for Jekyll and Docker-Template and my apps, I couldn't enforce keywords, I had to loosen my restrictions and add some logic I wouldn't normally add.

I think the drop should only be superficial until 4.0 though, don't test for it, don't care about it, but if there is a problem take it on a case-by-case until 4.0 and announce the change as official.

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Jan 21, 2016

Member

I think the drop should only be superficial until 4.0 though, don't test for it, don't care about it, but if there is a problem take it on a case-by-case until 4.0 and announce the change as official.

👍 from me on this.

Member

mattr- commented Jan 21, 2016

I think the drop should only be superficial until 4.0 though, don't test for it, don't care about it, but if there is a problem take it on a case-by-case until 4.0 and announce the change as official.

👍 from me on this.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Mar 1, 2016

Contributor

🎉

Contributor

envygeeks commented Mar 1, 2016

🎉

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