-
Notifications
You must be signed in to change notification settings - Fork 206
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
Discuss Ruby version support #503
Comments
My thoughts:
To drop any support, Semver says we need to mark the deprecation in at least one MINOR version before publishing a new MAJOR without the support. This would mean that 2.1.0 could announce the deprecation of Ruby versions we decide to drop and 3.0.0 could then drop the versions. In the meantime, I'm not sure we want to rush to release 3.0.0, given recent issues and how the rest of the ecosystem playing catch up still, but it's good to plan it out now. @kylog @binford2k @ahpook Your thoughts? |
I agree with all suggestions, except dropping |
Do any watchers of this issue have a feel for where people run puppet-lint? E.g. is it common for sites to run it with system ruby on EL6? (Please say no.) Anyway, the above sounds good to me with one minor tweak: I wouldn't allow failures with ruby 2.3. Puppet itself doesn't and the next puppet-agent release is planning to bundle 2.3. So better to stay ahead of the game. :) |
I guess I should have put a caveat on that, as I was assuming it may not pass 2.3 without some work (not sure why I thought that, but I did). I tested it in #505 and it works fine. |
@kylog Anecdata: when we ran EL6 on our linux build server (windows desktops after all), we used the PE3.7 vendored ruby and gem to install and use puppet-lint and other gems.Once we migrated to EL7, we used system ruby (2.0). I doubt we will change to use the vendored ruby again unless 2.0 becomes unsupported by multiple tools - 2.0 may not be supported by the ruby org, but it still works and vendors still support tools that rely on it. |
Yeah that makes sense. Tbh, 1.8.7 is by far the biggest problem child (e.g. the workarounds needed in #487), so I think we get most of our ease-of-maintenance win when we drop that. I agree that 2.0 being system ruby in EL7 makes a strong case for keeping 2.0 support around for a good while. |
Kylo merged 505 which means we are now testing against 1.8.7, 1.9.3, 2.0.0, 2.1.9, 2.2.4, 2.3.1. The question is then if we want to mark 1.8.7 or 1.8.7+1.9.3 as deprecated? Ben swayed me to keeping 1.9.3, since we don't see it breaking much if anything, so my vote is to only deprecate 1.8.7. |
Reasons to support each:
I am not fond of supporting 1.9.3 in projects, and I am especially not fond of supporting 1.8.7. EL6 is six years old but 14.04 is two and a half years old (Debian 7 is something I don't know) so dropping 1.8.7 seems valid, but 1.9.3 not so much, which is why I keep it around myself. Just some helpful info. |
+1 to dropping support for ruby 1.8.7. You can't run puppet v4 with ruby 1.8.7 so I don't need a newer version of puppet-lint that would support puppet v4 to support ruby 1.8.7 and can continue to use puppet-lint v1 when I'm using Puppet v3 / ruby 1.8.7. |
Out on the road I'm still seeing a ton of RHEL/CentOS6. People don't have the time/cycles to dedicate to training up their teams to RHEL7/CentOS7. I have a number of large clients that have a centralized development server with separate accounts, Vim/Emacs, etc. setups for devs and utilize system Ruby for installing puppet-lint. I'm just one guy, but if I'm seeing it "around" in the wild, I wonder what the percentage is "out there"? |
@cvquesty ah, that's super interesting. I would have assumed development environments would be faster to move up to newish releases. Tbh I have no good perspective on the percentage "out there" so definitely appreciate anecdotal info like yours. Thanks! |
+1 to @cvquesty as I'm regularly helping people do development on EL 6 systems, though we use RVM, so again, no need to continue supporting ruby 1.8.7. |
@cvquesty I support some EL6 systems myself, and we use either the puppet ruby side install, rbenv, or Docker for our testing. You could also, as @ghoneycutt mentioned, use rvm, or even Vagrant. If you hate yourself you can also use Redhat's devtoolset. It is 2016: no company should be using outdated system environments for development or testing. |
@cvquesty I feel you, we have some EL6, too. It is less the upgrade to EL7 and more to systemd that has delayed things (though leaps in php and such have had an effect, too). Regardless, we made our Dev server EL7 without upgrading everything else but had been using PE 3.7's AIO Ruby prior to that. We would not get rid of any deprecated version immediately anyway, we would simply mark it as deprecated until puppet-lint 3.0.0 lands. When 3.0.0 is released, then deprecated version support would be dropped (there is no ETA on 3.0.0, but I don't think a major version bump prior to 2017 would be real received, so 1Q2017 at the earliest). That would give some time for notice to be sent out and discovered by users, and maybe publicize a GH-pages article describing some AIO/rvm/rbenv workarounds, if people are interested in contributing that. With all of that in mind, would deprecating Ruby 1.8.7 in August 2016 be acceptable to the community? |
Many times the customer can be intransigent and say "no", which leaves you SOL if things go away. On the plus side, you now have a stick to whack said customer with, so I'm somewhat ambivalent in that regard. Sounds good to me, @rnelson0. Deprecate that mug. We'll deal with the ornery customers out here. |
FYI over the past few weeks, supporting Ruby 1.8.7 has gotten more difficult as a seeming legion of gems - json, json_pure, addressable, etc - have recently started requiring 1.9 or 2.0. To attempt to get ahead of this, I am proposing splitting the gem groups better in 768f646. However, if the pace of gems dropping <1.9 support increases, we may need to look at dropping 1.8.7 sooner. |
If you feel up to supporting Ruby <2.0.0 then more power to you, but that is a headache I have just eliminated across the board for myself as of beginning of August. Too many busted deps and too much special code and conditionals for those situations. I am not up to dealing with all of that overhead, but if you are, then carry forward and good luck! Who knows how Gosuke is still supporting 1.8.7 with serverspec... |
Why support Ruby 2.2? I thought that the puppet AIO is 2.1 and is transitioning to 2.3. Is there a modern OS that ships 2.2? |
More specifically we will support >=1.9.3. As described above, ubuntu 14.04 and Debian 7 ship with 1.9.3 and EL7 with 2.0.0. |
Fair point; I don't see a reason to test against ruby 2.2. I don't know of any OS shipping ruby 2.2. |
In #608/#610, Ruby 1.8.7 was marked as deprecated along with Puppet 3. I'm moving this to the 3.0 milestone as that is when we will drop the actual support. |
@ghoneycutt I added 2.2 to the list when >2.1 versions were added. I was unaware it was not in shipping OSes and we can drop it from the testing matrix if it helps. |
@rnelson0 +1 to not support ruby 2.2 or test with it since there is not a supported OS that needs it. |
puppet-lint has no declared Ruby version requirements in its gemspec, and tests against 1.8.7, 1.9.2, 1.9.3, 2.0.0, and 2.1.0. We should decide on what Ruby versions the program explicitly supports and adjust the gemspec and tests to match.
The text was updated successfully, but these errors were encountered: