[tests] Rationalise testing for JRuby 10.0.3

[chadlwilson]

https://www.jruby.org/2026/02/02/jruby-10-0-3-0

JRuby 10.0.3 corrects some issues with stdlib default gem packaging which were inconsistently with CRuby 3.4.0; which breaks "out-of-the-box" support on some versions which shouldn't have been working without workarounds earlier.

As noted in #397 (comment) we'll drop testing against Rails 6.1 and "official" support for the planned 1.3 stream.

[headius]

Something using the defunct mutex_m library in there?

[chadlwilson]

Yeah, Rails 6.1 which won’t be patched upstream and was already completely security EOL when Ruby 3.4 came out - now 16 months past security EOL, and 4 years past active support.

Forgot about this after the setup-ruby delayed publish was resolved, but think I decided just to drop the Rails 6.1 tests rather than hack in the dependency since Rails 6.1 is very past EOL now. But then couldn’t decide whether to drop them completely or drop only for 10.x - and got stuck in my own head.

I was generally trying to keep Rails 6.1 support working for as long as possible since there were jruby-rack breaking issues with 7.0, 7.1 and 7.2 in certain configurations until we released 1.2.x mid last year, even ignoring the warbler problems which were resolved a little later. But I suppose dropping the tests doesn’t mean it’s broken, just not “officially guaranteed to be working”.

I’m not sure if jruby ecosystem has a general policy to follow on such EOLs, but Google keeps support of (and precompiled gems) within their latest library versions for 1 year after official EOL of a CRuby release, which is one of the more generous policies. At the other end, rails and rubygems/bundler start dropping things immediately.

This is rather irritating, since GitHub dependabot always runs with latest rubygems/bundler and ignores locked versions or ruby version constraints in gemfiles. So a few weeks ago dependabot was permanently (?) broken for all jruby projects locked to jruby 9.4 simply because Cruby 3.1 is EOL. GitHub’s fault, not rubygems - but just an example of dysfunction in the ecosystem with respect to EOLs 😢

[headius]

I would argue the Ruby and rails communities have been too fast to eol some pretty significant releases, but there's not much we can do about that. We try to continue supporting older jruby versions and rails versions as long as there are active users helping us with that maintenance. I can't say the last time I heard from someone running rails 6.1.

[chadlwilson]

I can't say the last time I heard from someone running rails 6.1.

Yeah, in GoCD's case we were stuck on it until Feb 2025 due to use of the java servlet session store with jruby-rack, since auth is all fronted by Java/Spring framework. That was broken on rails 7.0 until jruby-rack 1.2.3 - but perhaps is an uncommon usage scenario, even more uncommon than use of jruby-rack itself.