Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[UPDATE] Drop support for Ruby 1.9.2 #415
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.
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:
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.