[UPDATE] Drop support for Ruby 1.9.2

[benlangfeld]

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]

+1

[lpradovera]

+1

[coveralls]

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

[coveralls]

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

[chewi]

DO IT! 💣

[chewi]

DO IT! 💣

[JustinAiken]

👍

[JustinAiken]

👍

[bklang]

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.

[bklang]

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]

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

[coveralls]

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

[benlangfeld]

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.

[benlangfeld]

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]

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

[coveralls]

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

[benlangfeld]

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]

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.

[coveralls]

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

[coveralls]

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