Skip to content
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

Open
rnelson0 opened this issue Jul 7, 2016 · 24 comments
Open

Discuss Ruby version support #503

rnelson0 opened this issue Jul 7, 2016 · 24 comments
Milestone

Comments

@rnelson0
Copy link
Collaborator

rnelson0 commented Jul 7, 2016

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.

@rnelson0
Copy link
Collaborator Author

rnelson0 commented Jul 7, 2016

My thoughts:

  • 1.8.7 is dead dead dead - 2+ years past EOL and Puppet itself no longer tests Puppet or modules against 1.8.7. Unfortunately, EL6 still uses 1.8.7. But without Ruby OR Puppet support, this makes no sense to support. I vote to drop this support.
  • 1.9.2 - I've not seen explicit use of this patch version anywhere else, 1.9.3 should cover the 1.9 train. I vote to drop this support.
  • 1.9.3 has no support from Ruby, but Puppet still tests against it. We could still test against it, but of course it limits some of the things we can do in code. I vote to drop this support, but could be convinced to leave it.
  • 2.0 has no support from Ruby, but Puppet still tests against it. In addition, EL7 provides Ruby 2.0 and will for years to come. Working with other projects, there seem to be few requested changes that work in 2.2 but not 2.0. I vote to keep this support through end of 2016 at least.
  • 2.1 has no support from Ruby, but Puppet still tests against it. Working with other projects, there seem to be few requested changes that work in 2.2 but not 2.1. I vote to keep this support through end of 2016 at least.
  • 2.2 is supported by Ruby. We do not test against it now. I vote we add this support.
  • 2.3 is supported by Ruby. We do not test against it now. I vote we add this support and place it under allow_failures.

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?

@binford2k
Copy link
Collaborator

I agree with all suggestions, except dropping 1.9.3. I believe that version should be kept around a little longer. I could easily be swayed though, if that's seen as limiting. The AIO vendored Ruby is 2.1.9p490 right now.

@kylog
Copy link
Collaborator

kylog commented Jul 7, 2016

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. :)

@rnelson0
Copy link
Collaborator Author

rnelson0 commented Jul 7, 2016

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.

@rnelson0
Copy link
Collaborator Author

rnelson0 commented Jul 8, 2016

@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.

@kylog
Copy link
Collaborator

kylog commented Jul 8, 2016

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.

@rnelson0
Copy link
Collaborator Author

rnelson0 commented Jul 8, 2016

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.

@mschuchard
Copy link

Reasons to support each:

  • 1.8.7: EL6
  • 1.9.3: Ubuntu 14.04 and Debian 7
  • 2.0.0: EL7

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.

@ghoneycutt
Copy link
Contributor

+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.

@cvquesty
Copy link
Contributor

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"?

@kylog
Copy link
Collaborator

kylog commented Jul 29, 2016

@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!

@ghoneycutt
Copy link
Contributor

+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.

@mschuchard
Copy link

mschuchard commented Jul 29, 2016

@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.

@rnelson0
Copy link
Collaborator Author

@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?

@cvquesty
Copy link
Contributor

cvquesty commented Aug 1, 2016

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.

@rnelson0 rnelson0 added this to the 2.1.0 milestone Aug 2, 2016
@rnelson0
Copy link
Collaborator Author

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.

@mschuchard
Copy link

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...

@binford2k
Copy link
Collaborator

Decision was made in triage today with @rnelson0, myself, and @rodjek to formally drop Ruby 1.8 at the 3.0 milestone.

@ghoneycutt
Copy link
Contributor

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?

@rnelson0
Copy link
Collaborator Author

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.

@kylog
Copy link
Collaborator

kylog commented Dec 23, 2016

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.

@rnelson0 rnelson0 mentioned this issue Dec 29, 2016
6 tasks
@rnelson0
Copy link
Collaborator Author

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.

@rnelson0 rnelson0 modified the milestones: 3.0.0, 2.1.0 Dec 30, 2016
@rnelson0
Copy link
Collaborator Author

@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.

@ghoneycutt
Copy link
Contributor

@rnelson0 +1 to not support ruby 2.2 or test with it since there is not a supported OS that needs it.

mterzo pushed a commit to mterzo/puppet-lint that referenced this issue Feb 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants