Remove version constraints for rubocop libraries #93
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These constraints make it more difficult to upgrade these libraries in projects that use rubocop-github. I think the idea here was that we'd be able to bump the version alongside the default config, but without locking to an exact version we can still end up with a config that is incompatible with certain rubocop version (see the unrecognized cop error in #86, for example). If anything, I'd prefer a `>=` constraint over a `<=`. That would allow us to bump the minimum constraint when we add new cops, but still freely upgrade in our projects as long as there are no config incompatibilities (which are less common anyway ever since RuboCop 1.0).
jhawthorn
approved these changes
Jan 14, 2022
Related to removing version constraints in 286944a, Running locked version of these in CI will help avoid unexpected failures for unrelated changes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These constraints make it more difficult to upgrade these libraries in
projects that use rubocop-github.
I think the idea here was that we'd be able to bump the version
alongside the default config, but without locking to an exact version we
can still end up with a config that is incompatible with certain rubocop
version (see the unrecognized cop error in
#86, for example).
If anything, I'd prefer a
>=constraint over a<=. That would allowus to bump the minimum constraint when we add new cops, but still
freely upgrade in our projects as long as there are no config
incompatibilities (which are less common anyway ever since RuboCop 1.0).