Doing a soft comparison with --required-version instead of a hard one.
See original GitHub issueIs your feature request related to a problem? Please describe.
Since Black just made it as stable, it would be nice to be able to set the --required-version
argument to something else other than a strict equality. For instance, something like 22 would encompass 22.1.0, 22.1.1, 22.2.0, etc.
Describe the solution you’d like
The solution would essentially be to modify this line to a more soft comparison: https://github.com/psf/black/blob/d038a24ca200da9dacc1dcb05090c9e5b45b7869/src/black/__init__.py#L477
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Understanding User Hard Matching and Soft Matching in ...
The actions are performed in the above sequence; Hard matching is attempted, before soft matching is attempted. If there's no match, a new...
Read more >Frameworks and Weak Linking - Apple Developer
Provides conceptual information and guidelines on how to create a framework.
Read more >Comparisons - Grammar - Academic Guides - Walden University
The comparative form is used to compare two people, ideas, or things. The superlative form with the word "the" is used to compare...
Read more >Everything you need to know to migrate from Mule 3 to Mule 4 ...
Big bang: This approach involves cutting over 100% of the traffic to the required version of the application. · Phased cutover: This approach ......
Read more >US9075661B2 - Placing objects on hosts using hard and soft ...
Objects are placed on hosts using hard constraints and soft constraints. ... to perform work both locally for cloud manager 105 and remotely...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Oh, by the way, you can use special keywords in the PR description so GitHub will automatically close an issue upon merge. You can read more here: https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword. This makes sure any issue that should be closed are in fact closed (and I won’t have to go proactively hunt for such issues!), keeping our very chaotic issue tracker ever so slightly less chaotic and scary 😃
Yes, this is a good idea.
I think we only need to accept the year, since that lets you use the stable style. I don’t think
22.1
makes much sense, as we provide no guarantee that releases that happen to fall within the same month are more compatible.