Require Ruby 2.6 or newer

[bastelfreak]

I don't see a reason why we need to keep Ruby 2.5 support. It's EoL since ages. Puppet Agent 7 uses Ruby 2.7, Puppetserver 7 uses jruby 9.3.14.0 which is equal to MRI Ruby 2.6.8. Dropping Ruby 2.6 allows us to use latest thor release.

[puppetlabs-jenkins]

Can one of the admins verify this patch?

[mhashizume]

Hey @bastelfreak, thanks for the PR. We made a run at doing this earlier this year, but some community members encountered issues because older versions of puppetserver 7 use JRuby 9.2.y.z, which targets Ruby 2.5 compatibility.

I opened an issue to bump up to Ruby 3.1 compatibility when the Puppet 7 series goes end-of-life (which is tentatively going to happen early next year): #2687. That issue has links to the previous attempt to require >= Ruby 2.6 and the revert.

[bastelfreak]

However, this broke compatibility with Puppetserver 7 in rare circumstances in which Facter 4.6.0/4.6.1 was being used in conjunction with Puppetserver < 7.9.0. Up until 7.9.0, Puppetserver used JRuby 9.2.y.z, which is compatible with MRI Ruby 2.5.

Why is that an issue? Doesn't that only happen if someone is on a very old version of puppetserver and updates facter in jruby on their own?

[mhashizume]

I agree it's not a common configuration but I don't mind erring on the side of caution in this instance, especially since we're almost at EOL for the Puppet 7 platform.

Are there Ruby 2.6 or Thor >= 1.3 features you'd like to see implemented?

[bastelfreak]

The problem is that on the one side people that package facter for other distributions now have to patch the gemspec file because distributions ship thor 1.3.1 or 1.3.2. On the other side I don't see a real reason why you should still support Ruby 2.5.

It should be fine to drop Ruby 2.5 now and make a facter 5 release, and in ~February when PE 2021 is finally EoL switch to Ruby 3.1 (puppetserver 8 uses jruby 9.4.8.0 which is MRI 3.1.4)?

[joshcooper]

The regression was reported by @ekohl in #2674 (comment) We try to maintain compatibility with agent and server packages within the same stream. So newer agent 7.21 with older puppetserver 7.x on the same host should in general work. If we don't maintain compatibility, then it can break puppetserver upgrades when using puppet to do the upgrade.