Define Ruby Compatibility Policy

[etagwerker]

Hi there,

I think it'd be a good idea to define a compatibility/maintenance policy for the Ruby versions of rubycritic and I think that it should follow the Ruby core team's policy.

I don't see why our (considerably smaller) maintenance team should try to support versions that are not supported by the Ruby maintenance team.

Ruby 2.7 has been EOLed for almost one year now:

Source: https://www.ruby-lang.org/en/downloads/branches/

I think we should only maintain Rubies that are currently supported:

That would mean that right now we should only support:

• 3.0
• 3.1
• 3.2
• 3.3

The advantage of something like this is that we could use the latest version of our dependencies (e.g. reek) -- Right now people expect RubyCritic to work with Ruby 2.7 (e.g. #477) and I think that's an unrealistic expectation.

I'd like to know your thoughts on this (especially @nunosilva800)

Thanks,
Ernesto

[faisal]

I think there are three questions here:

• For how long should the project maintain support for an EOL'd Ruby version: drop support immediately after EOL, or wait for some fixed period post-EOL before dropping support (such as six months after an EOL date)?

• Once the time comes, is it a hard-and-fast cutoff (immediately bump the minimum Ruby version) or a softer cutoff (possibly bumping the version requirement in a subsequent change, or only when some dependency updates or feature work necessitates it)?

• If taking the soft EOL path, and RubyCritic will support a post-EOL Ruby until some dependency wants to pull the minimum version forward, which of RubyCritic's dependencies are worth following to a new minimum Ruby version?

For a concrete example of this sort of decision, consider the discussion in #458 in light of where things stood eight months ago and where they stand now.

Considering those questions, I suggest a soft cutoff at the same time as Ruby EOL's a version. If it's to be later, then (based on when RubyCritics dependencies updated after the Ruby 2.7 EOL) it should be no more than six months after the EOL.

After the soft cutoff date date, RubyCritic's minimum version requirement should then move (to the oldest non-EOL'd Ruby version) when a runtime dependency no longer supports the EOL'd Ruby version.

When doing so, it might also be worth cutting a "final" EOL-supporting release that more tightly locks the dependency versions (such as @nunosilva800 suggested in #477 (comment)). For example, RubyCritic 4.9.1 could include #480 plus hold Reek to < 6.2, and RubyCritic 4.10.0 (or 5.0) drops Ruby 2.7 support.

[faisal]

There's a side but related issue around numbering: would bumping RubyCritic's major release numbering when Ruby bumps help with conveying the support situation? For example:

RubyCritic	New Ruby	(At some point) Dropping Support For Ruby
5.0	3.3	2.7
6.0	3.4	3.0

[nunosilva800]

I think we should only maintain Rubies that are currently supported:

I agree.

For how long should the project maintain support for an EOL'd Ruby version: drop support immediately after EOL, or wait for some fixed period post-EOL before dropping support (such as six months after an EOL date)?

I don't see the need to set a period "in calendar days". This repo is not a fast changing one, so there is less need to communicate with the world, how things are going.
When someone is contributing a new feature, change, cleanup, etc, and an older ruby version causes pain, we can just drop it.

Once the time comes, is it a hard-and-fast cutoff (immediately bump the minimum Ruby version) or a softer cutoff (possibly bumping the version requirement in a subsequent change, or only when some dependency updates or feature work necessitates it)?

Imo, only when feature work / dependencies updates are suggested.

If taking the soft EOL path, and RubyCritic will support a post-EOL Ruby until some dependency wants to pull the minimum version forward, which of RubyCritic's dependencies are worth following to a new minimum Ruby version?

The looser this gem is in terms of versioning the dependencies, the easier it is for projects to bundle it in.
For example, if there is a known compatability issue between RubyCritic v1.2.3 and Reek v2.3.4, but tests indicate all was working until Reek v2.3.3, we can cut a release of RubyCritic v1.2.4, that fixes Reek to v2.3.3 or less.
And start a new RubyCritic v1.3.x that requests at least Reek v2.3.4.

would bumping RubyCritic's major release numbering when Ruby bumps help with conveying the support situation?

I don't see that as helpful. If this was a library that must closely follow the ruby version, or an ecosystem of libraries under an organisation (like the myriad of react-xxx libs, or devise-123 plugins), then that is a helpful thing to do for the sake of clearer communication with the community.

Let's not forget that for most gems, and therefore RubyCritic as well, the ideal UX for a developer is to do bundle add rubycritic in their command line. Not expect them to peruse the myriad of versions and play some quick Tetris or back-and-forth trials until bundler says there are no errors.

[faisal]

The looser this gem is in terms of versioning the dependencies, the easier it is for projects to bundle it in.

For consideration: #489

[go2null]

for me, https://github.com/whitesmith/rubycritic#compatibility is quite sufficient as it lists the last version of RubyCritic to support a particular (J)Ruby version.