# 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. 1. 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. 1. 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`. 1. In the new config file, make sure it inherits from `base.yml` and disable the new rule. 1. 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](https://www.ruby-lang.org/en/downloads/branches/) 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: - [standard-custom](https://github.com/standardrb/standard-custom) - [standard-performance](https://github.com/standardrb/standard-performance) - [standard-rails](https://github.com/standardrb/standard-rails) - [standard-sorbet](https://github.com/standardrb/standard-sorbet) - [standard](https://github.com/standardrb/standard) 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