docs/RUBY_VERSIONS

Ruby versions

Handling new releases

When a new Ruby version comes out, you shouldn’t have to make any immediate
changes to Standard Ruby. The default configuration is the base.yml
configuration and should continue to work correctly.

Often, Rubocop will add new rules to encourage usage of new language features in
new Ruby versions. When that happens:

  1. Add the rule to the base.yml file and disable it.
  2. Assess the new rule and see if it should be added to Standard Ruby. If not, you’re done. If so, enable it in base.yml and read on.
  3. Add a new config file for the penultimate minor version of Ruby. For example, if the new version is 3.1 then the new config file would be for 3.0.
  4. In the new config file, make sure it inherits from base.yml and disable the new rule.
  5. In what was previously the latest config file, make sure it inherits from your new config file.

That should add new rules to Standard Ruby safely and gracefully.

Maintenance and support

We will support the actively maintained ruby versions from the ruby maintenance
policy along with the most
recently EOL version for an additional ~9 months, dropping support for EOL
versions around the time that a new supported ruby version is released and
added.

With the current ruby release cadence (new version near end of year, EOL drop
around April 1), this means we’ll have a release of all the Standard gems around
the new year which adds support for the new ruby version and drops support for
what was an already-EOL but still-supported older ruby version.

Coordination across gems

We will align versions/dependencies amongst the Standard gems:

This means keeping them consistent in regard to:

  • The minimum required ruby version configured in their gemspec
  • Using that version in their internal .standard.yml configurations
  • Including the full range of supported rubies in their CI ruby matrix