Define Ruby Compatibility Policy about rubycritic HOT 4 OPEN

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.

from rubycritic.

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:

from rubycritic.