Doing a soft comparison with --required-version instead of a hard one.

[freud14]

Is 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:

black/src/black/__init__.py

Line 477 in d038a24

if required_version and required_version != __version__:

[felix-hilden]

Fair request! We could break the version down into its parts and only compare until the specification ends. So e.g. 22.1 would accept 22.1.1 as well, and 22 would accept everything this year.

[JelleZijlstra]

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.

[felix-hilden]

Oh right, there's not really a point in going for more detail when the intention of the option was to require a certain style.

[freud14]

Juste made PR #2832. Let me know what you think.

[ichard26]

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 :)