Ruby 3.x support

[apjanke]

Ruby 3.x has been out since 2020-12-25. I'm not super familiar with Ruby, but it seems like Ruby 3.x is the main Ruby now, and this isn't a long-upgrade thing like the Python 3 release was. As of today, 2022-12-31, the Ruby Downloads page currently says Ruby 3.0.5, 3.1.3, and 3.2.0 are Stable, Ruby 2.7.7 is "in security maintenance phase (will EOL soon!)", and Ruby 2.6.10 is EOL.

Buuut, it looks like Debian is still on Ruby 2.5 in buster, 2.7 in bullseye (current Stable), and 3.1 in bookwork (current Testing). Hmm. I'm not sure what Debian's package release pickup policy is. I think they fix a minor version for a distro and pick up patch releases? Which means bullseye is on ronn-ng 0.9.x, and bookworm may or may not pick up ronn-ng 0.10.x. I'm working on an 0.10.x ronn-ng release now. Which I think means it's okay to upgrade to requiring Ruby 3.x, and imperative to at least support compatibility with Ruby 3.x.

Get Ronn-NG working under Ruby 3.x, and consider requiring it for Ronn-NG 0.10.x.

UPDATE: Based on feedback here, looking around the web, and the Ruby versions in major Linux distros, it looks like Ruby 2.x use is still widespread, and we should keep support for it. We will add support for Ruby 3.x, but it will not be a requirement for the foreseeable future. Renamed this issue from "Ruby 3.x support or requirement" to "Ruby 3.x support".

Related Issues

• https://github.com/apjanke/ronn-ng/issues/78

[deivid-rodriguez]

From the RubyGems side, we plan to also adopt ronn-ng in our CLI tool: https://github.com/rubygems/rubygems. So if Ruby 2.7 support can stay for now that's good for us because we'll keep Ruby 2.7 support during 2023. Probably going ahead of myself since we haven't yet migrated to ronn-ng, but I wanted to notice it anyways!

[apjanke]

Cool. I'd like to keep broad support for older Ruby versions if they are still in common use, and that looks feasible, so I think I'll keep the supported Ruby range at "2.4+ or 3.0+" for the foreseeable future. Will add Ruby 3.x support, but will not make it a requirement. I have updated the docs in the repo to reflect that.

[deivid-rodriguez]

For what it's worth, Ruby Core team and RubyGems team recommendation is to stick to supported versions. That currently means Ruby 2.7 or higher, although in RubyGems we'll still be keeping Ruby 2.6 support as well until the end of this year, when we will drop Ruby 2.6 and Ruby 2.7.

[apjanke]

Hmm. That makes sense, and would probably make my life easier.

Because Ronn-NG ships primarily as a standalone command/program, I'd like to keep supporting the major "live" distros that use it, by supporting the version of Ruby they ship. Debian Buster (10.x) is an LTS release which is supported until 2024-06-30, and it ships Ruby 2.5. Ubuntu 20.04 LTS is in main support until mid 2024, and runs... oh, Ruby 2.7.

MacOS is probably not an issue, because there Ronn-NG is installed with MacPorts or Homebrew, which ship their own newer Rubys, so Ronn-NG is not tied to the system Ruby version.

So I'd like to continue supporting Ruby 2.5 to support Debian Buster until it is EOL for LTS. But, supporting Ruby 2.5 in my current 0.10.x or whatever minor release series of Ronn-NG is probably the wrong way to do that: Debian fixes a minor version of its packages, so Debian Buster is still shipping Ronn-NG 0.8.x today and will keep doing so. The right way to do this is to probably have bugfix-only patch branches & release series for Ronn-NG, and produce, say, new 0.8.x patch releases with just bugfixes, for as long as an in-support major Linux release is shipping Ronn-NG 0.8.x, even while newer Ronn-NG 0.10+ releases come out, and the new 0.10+ minor release series can take a dependency on newer Rubys.

So now I think the right thing for Ronn-NG to do is:

• Each Ronn-NG minor release series has a fixed set of Ruby versions it supports and requires, which is the set of currently-supported Ruby versions at the time of the initial Ronn-NG x.y.0 minor release, as defined by Ruby Core and RubyGems.
• Ronn-NG patch releases for a given x.y.* series continue to support those same Ruby versions, even if they go out of support per Ruby Core/RubyGems, and patch releases for that Ronn-NG x.y minor release series will be made, independent of new minor Ronn-NG versions, as long as an in-support major distro is shipping that minor release of Ronn-NG.
  • Support for newly-created Ruby versions may be added in a patch release to a minor version, if it is easy and does not break back-compatibility with any other existing Ruby release supported by that Ronn-NG minor version.
• The patch releases for older Ronn-NG minor release series will be managed using long-lived branches in Git/GitHub.

Which I think means that Ronn-NG 0.10.x should support Ruby 2.7 (or maybe 2.6) or higher, and drop support for Ruby 2.4 and 2.5. And any bugs for Ronn-NG in Debian Buster should be fixed in a separate 0.8.x patch release series and Git branch, back-porting bugfixes as necessary, but not any new features.

Does that sound right/good to you?

[apjanke]

I think this is fixed now, with the changes from https://github.com/apjanke/ronn-ng/issues/87. It's running for me under Ruby 3.2 on my local Mac, and the GitHub Actions CI tests are passing under Ruby 3.0 and 3.1. Closing as fixed.

I left the doco saying "Ruby 2.4+" for now, but I think I'll change it to "Ruby 2.7+" in the near future, for either the 0.10 or 0.11 release series.