Rubocop: Please stop crashing lints between releases.

[envygeeks]

Here lately it seems like every other build of Rubocop is crashing my lints, because a configuration option is changed, or removed, rather drastically and suddenly, and instead of giving us at least a single version to update, it's decided that crashing is the best course of action (it's not.)

For people who have a few projects, this is not annoying, but for those of us who have hundreds of projects, these random crashes get annoying, and one might argue that we should just lock the version, but then that becomes a problem in and of itself.

Can you please consider not crashing, and instead provide a deprecation period.

[mikegee]

The most recent discussion on this topic is yonder: https://github.com/bbatsov/rubocop/issues/5612

I'm struck by your mention of the failures being "random". I manage a Rubocop CI check on >100 projects without unexpected failures by tracking Rubocop's version and upgrading it after reviewing a run on the new version. Perhaps a workflow tweak would go a long way here?

[envygeeks]

Who plans on funding this CI for these open source projects so that I can tweak everything?

[Drenmi]

Would it make a considerable difference? The way it seems:

Before:

1. Upgrade RuboCop.
2. Crash on deprecated configuration.
3. Update configuration.

After:

1. Upgrade RuboCop.
2. Get deprecation message.
3. Update configuration.

The action required from the end user is essentially the same?

[envygeeks]

Sure, if you phrase it in a way that shuts down this ticket.

[Drenmi]

I'm not trying to shut down the ticket. I'm trying to understand the pains, so we can find a good solution. The deprecation will add considerable development effort, so want the problem statement to be clear so we solve the right problem. 🙂

[Drenmi]

Closing as duplicate, but the discussion will go on in #5612.

[envygeeks]

That would work too! Thanks for pointing that out.