I see no reason to drop Ruby 2.4 or 2.5 from the test matrix, until there are Ruby 2.6 features that we want to use in Rack.

@jeremyevans I think there are failures in the CI on some of the PRs @ioquatix sent. Upstream has EOL'd everything through (and including) Ruby 2.6, meaning that if any of our users are running those versions they could be subject to security issues anyway. I don't think it's worth our time to keep these versions green when users shouldn't be using these versions. If someone wants to keep those branches green (on their own forks or something) I don't care, but I don't think ensuring these old versions are green should block incoming PRs.

@tenderlove The failure on Ruby 2.5 in @ioquatix was due to an unnecessary and unused library in the Gemfile used in CI, not due to any code in rack. See #2021 for a fix.

I'm fine with Ruby 2.4/2.5 failing in CI not being a blocker for merging PRs. I volunteer to fix any Ruby 2.4/2.5 CI issue. Assuming that is acceptable solution, can we close this?

I'm fine with Ruby 2.4/2.5 failing in CI not being a blocker for merging PRs. I volunteer to fix any Ruby 2.4/2.5 CI issue. Assuming that is acceptable solution, can we close this?

If you want to ensure older versions work, I think that's great. But I'm not sure that "until there are Ruby 2.6 features that we want to use in Rack." is the right yard/meter stick for judging when we drop support for particular Ruby versions. I'll guess that any new language feature can be written in terms of an older language feature, which means we could be supporting Ruby versions in perpetuity.

Can we come up with less subjective criteria for supporting Ruby versions? I think supporting what upstream supports is good, but I'm open to other ideas.

All that said, if you want to keep 2.4/2.5/2.6 (or whatever versions we decide aren't supported) green, that's great. I'd just like a more clear policy on what versions we do and don't support. Also happy to keep unsupported versions in CI as long as we're OK with merging red PRs.

If you want to ensure older versions work, I think that's great. But I'm not sure that "until there are Ruby 2.6 features that we want to use in Rack." is the right yard/meter stick for judging when we drop support for particular Ruby versions. I'll guess that any new language feature can be written in terms of an older language feature, which means we could be supporting Ruby versions in perpetuity.

Can we come up with less subjective criteria for supporting Ruby versions? I think supporting what upstream supports is good, but I'm open to other ideas.

Basically, I don't want to drop support for Ruby versions just because they are old. We should drop them then they become a problem for us. For example, we dropped Ruby 2.3 support mostly so we could use Regexp#match? without having to deal with refinements, and also because we were already using Array#sum (fba6819).

If we want to use Ruby 2.5 or 2.6 features to make rack better, that's a good reason to drop support for older versions. I just don't want to drop support just to drop it. When we drop support for old Ruby versions, we make it significantly more difficult for users who are on older Ruby and Rack versions to upgrade to the current versions, because they need to use multi-phase upgrades. It is significantly easier on such users if they can upgrade to the current version of Rack with their existing Ruby version, then upgrade Ruby to the current version. The more we drop support for older versions, the more steps we force on such users. I don't want to get in the way of progress, but I do want to make it as easy as possible to go from older Ruby and Rack versions to the current ones.

Regarding Ruby 2.6 specifically, while not supported by CRuby, JRuby 9.3 is still supported by the JRuby team (I think through the end of the year), and that has CRuby 2.6 compatibility. So even if we dropped Ruby 2.4 and 2.5 support, I don't think we should drop Ruby 2.6 support until JRuby 9.3 is out of support.

All that said, if you want to keep 2.4/2.5/2.6 (or whatever versions we decide aren't supported) green, that's great. I'd just like a more clear policy on what versions we do and don't support. Also happy to keep unsupported versions in CI as long as we're OK with merging red PRs.

That approach is fine fine with me.

Regarding Ruby 2.6 specifically, while not supported by CRuby, JRuby 9.3 is still supported by the JRuby team (I think through the end of the year), and that has CRuby 2.6 compatibility. So even if we dropped Ruby 2.4 and 2.5 support, I don't think we should drop Ruby 2.6 support until JRuby 9.3 is out of support.

I think this is a good reason to support 2.6+. If we can make the other Ruby versions "optional" builds that would be great (though I'm not sure if we have to pay for that feature or not).

Personally, I'm keen to be more aggressive with upgrades because the regex improvements in 3.2 mean we can stop fielding ReDoS security issues. Obviously dropping support for everything except 3.2 is a non-starter, but I'd very much like to know there is a light at the end of the tunnel which is why I'd prefer a time based approach.

Even for Regexps that cannot use the ReDoS mitigations, being able to use Regexp timeout features in 3.2 would be a reason to drop older versions, once CRuby and JRuby stop supporting them. Again, I'm definitely in favor of dropping unsupported Ruby versions if rack can benefit from features in newer Ruby versions.

I'm personally happy with dropping older releases because as a maintainer it avoids issues I can't debug consuming a large amount of my time. Like both of you, I have limited time, and I don't want to spend it debugging old ruby releases.

I also agree, I want to use more modern code, but I imagine the argument will be "this new code isn't sufficient for dropping the old Ruby version, just use a more compatible way". But that discussion in and of itself is an example of the former point.

Realistically, the number of people installing Rack 3.1 on Ruby < 2.7 is going to be tiny in practice (probably zero). As a maintainer of an open source project, it's not our job to help people who are stuck on really old versions and have delayed updating systems (at their own peril, security being a big one).

By testing and supporting these old versions, one coud argue we are tacitly supporting their continued use... which isn't something I personally recommend either.

I personally think that at the point of release, only non-EOL Rubies need to be supported. This sets a clear expectation around compatibility. Obviously this doesn't change past releases.

Maybe to ask the opposite question, what is the strong argument for keeping Ruby 2.4 and 2.5?

I'm personally happy with dropping older releases because as a maintainer it avoids issues I can't debug consuming a large amount of my time. Like both of you, I have limited time, and I don't want to spend it debugging old ruby releases.

This is a non-issue if you don't have to do any work. @tenderlove mentioned ignoring CI failures for 2.4 and 2.5, which I implemented in #2023. So neither of you will need to worry about that, I will be fully responsible for fixing any fallout.

I also agree, I want to use more modern code, but I imagine the argument will be "this new code isn't sufficient for dropping the old Ruby version, just use a more compatible way". But that discussion in and of itself is an example of the former point.

If there are significant advantages to dropping support for unsupported Ruby versions, I'm fine with doing so. This isn't the case for Ruby 2.4 or 2.5, yet.

Realistically, the number of people installing Rack 3.1 on Ruby < 2.7 is going to be tiny in practice (probably zero).

I'm sure the number is greater than zero. If you ignore Rails usage (since Rails 7.0.x still requires Rack 2 and Ruby >2.7), my guess would be 2-5%. If you look at surveys of Ruby usage, about 30% of users are using Ruby versions that are no longer supported.

Maybe to ask the opposite question, what is the strong argument for keeping Ruby 2.4 and 2.5?

I gave my reasoning earlier in the thread: #2020 (comment)

I'm sure the number is greater than zero. If you ignore Rails usage (since Rails 7.0.x still requires Rack 2 and Ruby >2.7), my guess would be 2-5%. If you look at surveys of Ruby usage, about 30% of users are using Ruby versions that are no longer supported.

This is RedHat's (also RailsLTS) bread and butter though, right? 😜

If @jeremyevans is interested in keeping 2.4 and 2.5 green then I think adding them as optional builds is a fine compromise. I don't want to stop him if he wants to do the work. As a project though, I think 2.6+ (the oldest version supported by either JRuby or CRuby) is good.

So it sounds like we can close this, and merge #2023 (ignore 2.4/2.5 failures) and #2021 (fix 2.5 CI failure due to psych mismatch issue caused by unnecessary rdoc dependency).

Sorry to beat a dead horse but I have some things I feel I need to say and get clarification on.

I'm sure the number is greater than zero. If you ignore Rails usage (since Rails 7.0.x still requires Rack 2 and Ruby >2.7), my guess would be 2-5%. If you look at surveys of Ruby usage, about 30% of users are using Ruby versions that are no longer supported.

Given that Rack 3.1 is not even released yet, I don't think anyone is using it :p

Realistically though, are people running Rack 3.1 on Ruby 2.4 the kind of users we want to support? Regarding upgrade paths, we have one: Rack 3.0 will forever support Ruby 2.4+ and that's the correct upgrade path, since it issues deprecation warnings. People (in this group) going straight to 3.1 will be in for a shock. So, I ask again, what are the actual positive reasons for keeping 2.4 and 2.5 - not the reason for not dropping them, but the reason for keeping them. I'd like to have that documented somewhere. "Basically, I don't want to drop support for Ruby versions just because they are old." is not a reason to keep something, it's a reason not to drop something. I want to know WHY we want to keep it. What's the advantage to us as maintainers and a project?

This is RedHat's (also RailsLTS) bread and butter though, right? stuck_out_tongue_winking_eye

Sure, but I don't think these platforms are going to adopt Rack 3.1+ either.

If @jeremyevans is interested in keeping 2.4 and 2.5 green then I think adding them as optional builds is a fine compromise. I don't want to stop him if he wants to do the work.

Sure, but in reality this is still a maintenance burden for everyone contributing to Rack.

As a project though, I think 2.6+ (the oldest version supported by either JRuby or CRuby) is good.

I agree with this.

I normally support non-EOL Rubies at the time of a major release + JRuby and TruffleRuby latest release if possible.

We should probably document the compatibility expectations.

So, I ask again, what are the actual positive reasons for keeping 2.4 and 2.5 - not the reason for not dropping them, but the reason for keeping them.

I don't think we're keeping them. We've made them optional builds. @jeremyevans said he's interested in keeping them green, and if he wants to do that, I think it's fine. As a project though, we don't officially support them (which is why they are optional builds now).

Sure, but I don't think these platforms are going to adopt Rack 3.1+ either.

Sorry, I was making a joke. RedHat / RailsLTS get paid to maintain older versions.

I normally support non-EOL Rubies at the time of a major release + JRuby and TruffleRuby latest release if possible.

We should probably document the compatibility expectations.

This is the plan, and I agree we should document that.