Should a New Rule Bump the Major or Minor Version?

[zavoloklom]

I'm currently working on versioning rules for a project and would like to gather input from the community:

When a new rule is introduced, should it trigger a major version bump (e.g., 1.0.0 → 2.0.0) or a minor version bump (e.g., 1.0.0 → 1.1.0)?

Arguments for a Major Version Bump:

• Adding a new rule might be considered a breaking change if it flags issues in previously valid code.
• Signaling that the project introduces substantial changes ensures users proceed with caution.

Arguments for a Minor Version Bump:

• Adding a new rule doesn't technically break existing functionality, so it's not a traditional breaking change.
• Users still have control over enabling or disabling the new rule.
• It keeps the versioning less aggressive, avoiding unnecessary major bumps.

Please vote and share your thoughts on which approach better fits this scenario and why!

[zavoloklom]

@salzig @szymon-filipiak @AdamVig Hi guys!
Since you contributed to this project, I really appreciate your opinion on this question. If you haven't had a chance to vote yet, I kindly encourage you to do so. Thank you!

[salzig]

• add rules in disabled state with minor.
• enable all by default disabled when releasing a major.
• maybe add a config option "I feel lucky and love my pipelines to randomly fail" that enables rules normally disabled.

[zavoloklom]

Thank you!
Last one seems like an update on April 1st :)

[salzig]

I personally like the last option as an easy way to run locally with all rules, without altering a lot.

[AdamVig]

I agree with the above.

I'm not sure exactly what ESLint does but copying their policy might be a good idea.

[zavoloklom]

Thank you for your opinion!
It was my first thought, but ESLInt don't have built-in rules, they provide rules as a separate package and I'm not ready for it yet

[szymon-filipiak]

I share a similar view on this one as @salzig and @AdamVig

It's a nice middle ground.

[zavoloklom]

Thank you!