Define a stability policy

[JelleZijlstra]

Fixes #2394. Eventually fixes #517.

This is essentially @pradyunsg's suggestion from #2394. I suggest that at the
same time we start the formal stability policy, we take a few other disruptive steps
and drop Python 2 and the "b" marker.

[felix-hilden]

The cogs are turning and it's exciting! 😄 As discussed, the policy is sensible. And having a CLI flag instead of, say two branches with different release lines seems more manageable.

[pradyunsg]

A few suggestions inline, and a overall note.

Define this stability policy as something that applies to the stable releases, not all releases. I would also recommend against making any formatting changes when this policy is adopted -- it would be a good idea to have a beta release prior to the stable release, that contains any potentially disruptive changes. IMO your last beta release and first stable release only have one difference -- the version number -- that's how you know it's good enough to call stable. :)

While dropping Python 2 is -- as you'd know -- something I strongly recommend doing, I do recommend separating that from the discussion of adopting this policy. :)

[ichard26]

While dropping Python 2 is -- as you'd know -- something I strongly recommend doing, I do recommend separating that from the discussion of adopting this policy. :)

Strong +1 from me as these things aren't closely connected other than that they may be done at the same time.

re. making the first stable release basically a version bump dropping the B (too lazy to copy and paste :p)

I don't feel as strongly as you but this seems like a good idea.

Thank you for the review @pradyunsg, it's well appreciated :)

[hauntsaninja]

What's the status on parsing Python 3.10? Depending on the details, I suspect it might be a lot more work than otherwise to actually keep this guarantee through swapping out parsers.

As pradyunsg says elsewhere:

If you cut the stable release in Feb 2022 or April 2022, nothing is going to break. Give yourselves the flexibility to do things at whatever pace, instead of promising deadlines to largely ambivalent users.

[JelleZijlstra]

What's the status on parsing Python 3.10? Depending on the details, I suspect it might be a lot more work than otherwise to actually keep this guarantee through swapping out parsers.

There's been no real progress. Most likely it will be a big rewrite, so you're right that that may make it hard to guarantee no format changes.

[hauntsaninja]

Okay, if it's going to be a big rewrite then I see the two options as:
a) postpone stability policy until after rewrite,
b) add stability policy, only use newly rewritten code with black --future (i.e. users need a flag to format match statements), keep all existing code around until 2023.

There is of course a third option, but one I'm skeptical of:
c) add stability policy, delete existing code, assume big rewrite results in no formatting changes / treat every formatting change it introduces as a bug that surprises users who now expect stability

My preference would be for a). It might be the case that I'm pessimistic about c), but the only way to find out for sure would be to make progress on the rewrite.

[ambv]

We can do further improvements on this going forward. Thanks!

[ichard26]

re. Python 3.10 rewrite

We're in a slightly better state as the great work by @isidentical means Black (or specifically blib2to3) supports 3.10 pretty well at this point. We still have the fact the parser is still LL(1) and now has a somewhat permissive grammar meaning we'd have to rewrite the project eventually if Python gets even more new PEG syntax in future releases. This gives us more time and less pressure but then again the whole problem is the complete lack of resources as per usual in FOSS :/

It's probably worth fleshing out a basic transition plan after we finally get Black stable, but to be honest I have no idea where we'd start.