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

[UPDATE] Drop support for Ruby 1.9.2 #415

Merged
merged 1 commit into from Jan 13, 2014

Conversation

Projects
None yet
6 participants
@benlangfeld
Member

benlangfeld commented Jan 2, 2014

Arguments:

  • Ruby 1.9.2 reached EOL (does not receive security fixes)
  • Upgrading from 1.9.2 to 1.9.3 is trivial
  • Most people on 1.9 are already on 1.9.3
  • Maintaining support of Adhearsion and related projects on unmaintained Ruby versions is a disservice to our users. There are enough reasons for an upgrade regardless of Adhearsion's support (security issues, etc), suggesting that it's ok to continue using unmaintained language versions is poor advice, and attempting to maintain support distracts us from improving the project (security, bugs, performance and features) on modern maintained platforms.

I suggest that Adhearsion's versioning policy should state that external dependencies (Ruby versions, Asterisk/FS versions) will be supported within a major release of Adhearsion until the point at which they reach their own EOL date, at which point Adhearsion's support for those dependencies will cease to be guaranteed.

Review please @bklang.

@lpradovera

This comment has been minimized.

Show comment
Hide comment
@lpradovera
Member

lpradovera commented Jan 2, 2014

+1

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jan 2, 2014

Coverage Status

Coverage remained the same when pulling a02ba67 on feature/deprecate_old_rubies into 6706853 on develop.

coveralls commented Jan 2, 2014

Coverage Status

Coverage remained the same when pulling a02ba67 on feature/deprecate_old_rubies into 6706853 on develop.

@chewi

This comment has been minimized.

Show comment
Hide comment
@chewi

chewi Jan 2, 2014

Member

DO IT! 💣

Member

chewi commented Jan 2, 2014

DO IT! 💣

@JustinAiken

This comment has been minimized.

Show comment
Hide comment
@JustinAiken

JustinAiken Jan 2, 2014

Member

👍

Member

JustinAiken commented Jan 2, 2014

👍

@bklang

This comment has been minimized.

Show comment
Hide comment
@bklang

bklang Jan 2, 2014

Member

I have concerns with this.

The first is that it violates SemVer, which is a promise we have made to the community. Any backward incompatible changes (which to my mind means anything that breaks when you do nothing more than "bundle update") are disallowed within a minor version.

The second is that, while it is easy for developers to upgrade Ruby versions, it's something else entirely for apps running in production. Sysadmins are worried about things like OS packages, integrating with Chef or Puppet, ensuring that consistent versions get deployed across servers and even environments (dev vs. production), etc. They also don't have the advantage of being familiar with the Ruby ecosystem. Certainly it's not a good idea to be on an old version of Ruby after it is unsupported, but it does happen.

The third is that this change does not sufficiently alert users that they are doing something dangerous, when they don't expect danger. More on how to address this in a second.

With all of the above said, I can see the merit in dropping official support once a language is unsupported upstream, and provided the upgrade path is relatively painless (ie. no application changes should be required to go from 1.9.2 to 1.9.3). Still, we have a responsibility to our users. I have three requests I'd like to see done before I sign off on this change, and the policy it implies:

  1. A note be sent to the Adhearsion mailing list detailing the rationale behind the change and inviting comment. This venue is good for discussion, but not everyone will see it.
  2. A large, prominent notice in both the README and the Changelog.
  3. A post-install note in the gemspec, similar to what you see when installing HAML. This is important because it's the last line of defense against someone accidentally bundle updating and not realizing that a breaking change has occurred.

2 and 3 above should be a part of this PR.

We should also document our support policy somewhere, including @benlangfeld's original rationale. We should also add a note to the Best Practices page about how to lock Gemfiles to a version of Adhearsion, and make that be compatible with the Adhearsion release/support policy.

Member

bklang commented Jan 2, 2014

I have concerns with this.

The first is that it violates SemVer, which is a promise we have made to the community. Any backward incompatible changes (which to my mind means anything that breaks when you do nothing more than "bundle update") are disallowed within a minor version.

The second is that, while it is easy for developers to upgrade Ruby versions, it's something else entirely for apps running in production. Sysadmins are worried about things like OS packages, integrating with Chef or Puppet, ensuring that consistent versions get deployed across servers and even environments (dev vs. production), etc. They also don't have the advantage of being familiar with the Ruby ecosystem. Certainly it's not a good idea to be on an old version of Ruby after it is unsupported, but it does happen.

The third is that this change does not sufficiently alert users that they are doing something dangerous, when they don't expect danger. More on how to address this in a second.

With all of the above said, I can see the merit in dropping official support once a language is unsupported upstream, and provided the upgrade path is relatively painless (ie. no application changes should be required to go from 1.9.2 to 1.9.3). Still, we have a responsibility to our users. I have three requests I'd like to see done before I sign off on this change, and the policy it implies:

  1. A note be sent to the Adhearsion mailing list detailing the rationale behind the change and inviting comment. This venue is good for discussion, but not everyone will see it.
  2. A large, prominent notice in both the README and the Changelog.
  3. A post-install note in the gemspec, similar to what you see when installing HAML. This is important because it's the last line of defense against someone accidentally bundle updating and not realizing that a breaking change has occurred.

2 and 3 above should be a part of this PR.

We should also document our support policy somewhere, including @benlangfeld's original rationale. We should also add a note to the Best Practices page about how to lock Gemfiles to a version of Adhearsion, and make that be compatible with the Adhearsion release/support policy.

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jan 2, 2014

Coverage Status

Coverage remained the same when pulling e01dca3 on feature/deprecate_old_rubies into 6706853 on develop.

coveralls commented Jan 2, 2014

Coverage Status

Coverage remained the same when pulling e01dca3 on feature/deprecate_old_rubies into 6706853 on develop.

@benlangfeld

This comment has been minimized.

Show comment
Hide comment
@benlangfeld

benlangfeld Jan 2, 2014

Member

So #1 and #2 are done, and to replace #3 I went ahead with specifying a minimum Ruby version in the gemspec, which does this:

{15:04}~/code/adhearsion:feature/deprecate_old_rubies ✗
➭ gem install adhearsion                                                                                            [1.9.2]
ERROR:  Error installing adhearsion:
    adhearsion requires Ruby version >= 1.9.3.
Member

benlangfeld commented Jan 2, 2014

So #1 and #2 are done, and to replace #3 I went ahead with specifying a minimum Ruby version in the gemspec, which does this:

{15:04}~/code/adhearsion:feature/deprecate_old_rubies ✗
➭ gem install adhearsion                                                                                            [1.9.2]
ERROR:  Error installing adhearsion:
    adhearsion requires Ruby version >= 1.9.3.
@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jan 2, 2014

Coverage Status

Coverage remained the same when pulling 8fbba69 on feature/deprecate_old_rubies into 6706853 on develop.

coveralls commented Jan 2, 2014

Coverage Status

Coverage remained the same when pulling 8fbba69 on feature/deprecate_old_rubies into 6706853 on develop.

@benlangfeld

This comment has been minimized.

Show comment
Hide comment
@benlangfeld

benlangfeld Jan 10, 2014

Member

If no further comment is received, this will be merged to the develop branch on Monday 13th January, and will be included in the upcoming Adhearsion 2.5.0 release.

Member

benlangfeld commented Jan 10, 2014

If no further comment is received, this will be merged to the develop branch on Monday 13th January, and will be included in the upcoming Adhearsion 2.5.0 release.

@benlangfeld benlangfeld merged commit bfabeac into develop Jan 13, 2014

1 check was pending

default The Travis CI build is in progress
Details

@benlangfeld benlangfeld deleted the feature/deprecate_old_rubies branch Jan 13, 2014

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Jan 13, 2014

Coverage Status

Coverage remained the same when pulling bfabeac on feature/deprecate_old_rubies into 430a833 on develop.

coveralls commented Jan 13, 2014

Coverage Status

Coverage remained the same when pulling bfabeac on feature/deprecate_old_rubies into 430a833 on develop.

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