Versioning

RuboCop is stable between major versions, both in terms of API and cop configuration. We aim the ease the maintenance of RuboCop extensions (by keeping the API stable) and the upgrades between RuboCop releases (by not enabling new cops and changing the configuration of existing cops). All big (breaking) changes are reserved for major releases.

Release Policy

We’re following Semantic Versioning. API compatibility between major releases is a big concern, as there are many RuboCop extensions that can be affected by breaking API changes.

Dropping runtime support for a particular Ruby version is not considered a breaking change, as it doesn’t affect clients in any way. They are simply restricted to the last version of RuboCop supporting their Ruby runtime. In practice this means that dropping runtime support for Ruby versions can happen in any minor release.

The development cycle for the next minor (feature) release starts immediately after the previous one has been shipped. Bug-fix (point) releases (if any) address only serious bugs and never contain new features.

Here are a few examples:

  • 1.1.0 - Feature release

  • 1.1.1 - Bug-fix release

  • 1.1.2 - Bug-fix release

  • 1.2.0 - Feature release

Prior to RuboCop 1.0 bumps of the minor (second) version number were considered major releases and always included new features and/or changes to existing features.

Pending Cops

In the early versions of RuboCop a common source of frustration was that new cops were added to pretty much every release, and as they were enabled by default, every upgrade resulted in broken CI builds and trying to figure out what exactly was changed. After considering many options to address this eventually we opted for an approach that limits these type of changes to major RuboCop releases.

Now new cops introduced between major versions are set to a special pending status and are not enabled by default. A warning is emitted if such cops are not explicitly enabled or disabled in the user configuration. Here’s one such message:

The following cops were added to RuboCop, but are not configured. Please
set Enabled to either `true` or `false` in your `.rubocop.yml` file:
 - Style/HashEachMethods (0.80)
 - Style/HashTransformKeys (0.80)
 - Style/HashTransformValues (0.80)
For more information: https://docs.rubocop.org/rubocop/versioning.html

You can see that 3 new cops were added in RuboCop 0.80 and it’s up to you to decide if you want to enable or disable them.

Occasionally, some new cops will be introduced as disabled by default. Usually, this means that we believe that the cop is useful, but not for everyone. Typical cases might be the enforcement of programming styles that are not very common in the wild, or cops that yield too many false positives (so you’d run them manually from time to time, instead of running them all the time).

Enabling/Disabling Pending Cops in Bulk

To suppress this message set NewCops to either enable or disable in your .rubocop.yml file. You can use following configuration or the --enable-pending-cops command-line option, to enable all pending cops in bulk:

AllCops:
  NewCops: enable

Alternatively, you can use following configuration or the --disable-pending-cops command-line option, to disable all pending cops in bulk:

AllCops:
  NewCops: disable
The command-line options takes precedence over .rubocop.yml file.

Enabling/Disabling Individual Pending Cops

Finally, you can enable/disable individual pending cops by setting their Enabled configuration to either true or false in your .rubocop.yml file:

Style/ANewCop is an example of a newly added pending cop:

Style/ANewCop:
  Enabled: true

or

Style/ANewCop:
  Enabled: false
On major RuboCop version updates (e.g. 1.0 → 2.0), all pending cops are enabled in bulk.