Define a stability policy (#2529)

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.

Co-authored-by: Pradyun Gedam <pradyunsg@gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>

diff --git a/CHANGES.md b/CHANGES.md
index 864f0a54410b33cadeaa8ee9b2a5d3817aa9c9d1..2a3a60f82c68f1ba3d86766011986baa99830b3f 100644 (file)
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -4,6 +4,7 @@
 
 ### _Black_
 
 
 ### _Black_
 

+- Document stability policy, that will apply for non-beta releases (#2529)

 - Add new `--workers` parameter (#2514)
 - Fixed feature detection for positional-only arguments in lambdas (#2532)
 - Bumped typed-ast version minimum to 1.4.3 for 3.10 compatiblity (#2519)
 - Add new `--workers` parameter (#2514)
 - Fixed feature detection for positional-only arguments in lambdas (#2532)
 - Bumped typed-ast version minimum to 1.4.3 for 3.10 compatiblity (#2519)

diff --git a/docs/faq.md b/docs/faq.md
index c361addf7ae2b21b69ef1860824c1e02e12f0887..9fe53922b6d7e56bce269a6fdaae0e59ee7db150 100644 (file)
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -31,6 +31,10 @@ pragmatism. However, _Black_ is still in beta so style changes are both planned
 still proposed on the issue tracker. See
 [The Black Code Style](the_black_code_style/index.rst) for more details.
 
 still proposed on the issue tracker. See
 [The Black Code Style](the_black_code_style/index.rst) for more details.
 

+Starting in 2022, the formatting output will be stable for the releases made in the same
+year (other than unintentional bugs). It is possible to opt-in to the latest formatting
+styles, using the `--future` flag.
+

 ## Why is my file not formatted?
 
 Most likely because it is ignored in `.gitignore` or excluded with configuration. See
 ## Why is my file not formatted?
 
 Most likely because it is ignored in `.gitignore` or excluded with configuration. See


@@ -71,9 +75,11 @@ disabled-by-default counterpart W504. E203 should be disabled while changes are
 ## Does Black support Python 2?
 
 For formatting, yes! [Install](getting_started.md#installation) with the `python2` extra
 ## Does Black support Python 2?
 
 For formatting, yes! [Install](getting_started.md#installation) with the `python2` extra

-to format Python 2 files too! There are no current plans to drop support, but most
-likely it is bound to happen. Sometime. Eventually. In terms of running _Black_ though,
-Python 3.6 or newer is required.
+to format Python 2 files too! In terms of running _Black_ though, Python 3.6 or newer is
+required.
+
+Note that this support will be dropped in the first stable release, expected for
+January 2022. See [The Black Code Style](the_black_code_style/index.rst) for details.

 
 ## Why does my linter or typechecker complain after I format my code?
 
 
 ## Why does my linter or typechecker complain after I format my code?
 

diff --git a/docs/the_black_code_style/index.rst b/docs/the_black_code_style/index.rst
index 4693437be8bb31c26cb791ded702d18ce860ac97..7c2e1753937cb61159fb88e6bb29d32f78d8d66f 100644 (file)
--- a/docs/the_black_code_style/index.rst
+++ b/docs/the_black_code_style/index.rst
@@ -9,9 +9,33 @@ The Black Code Style
 
 *Black* is a PEP 8 compliant opinionated formatter with its own style.
 
 
 *Black* is a PEP 8 compliant opinionated formatter with its own style.
 

-It should be noted that while keeping the style unchanged throughout releases is a
-goal, the *Black* code style isn't set in stone. Sometimes it's modified in response to
-user feedback or even changes to the Python language!
+While keeping the style unchanged throughout releases has always been a goal,
+the *Black* code style isn't set in stone. It evolves to accomodate for new features
+in the Python language and, ocassionally, in response to user feedback.
+
+Stability Policy
+----------------
+
+The following policy applies for the *Black* code style, in non pre-release
+versions of *Black*:
+
+- The same code, formatted with the same options, will produce the same
+  output for all releases in a given calendar year.
+
+  This means projects can safely use `black ~= 22.0` without worrying about
+  major formatting changes disrupting their project in 2022. We may still
+  fix bugs where *Black* crashes on some code, and make other improvements
+  that do not affect formatting.
+
+- The first release in a new calendar year *may* contain formatting changes,
+  although these will be minimised as much as possible. This is to allow for
+  improved formatting enabled by newer Python language syntax as well as due
+  to improvements in the formatting logic.
+
+- The ``--future`` flag is exempt from this policy. There are no guarentees
+  around the stability of the output with that flag passed into *Black*. This
+  flag is intended for allowing experimentation with the proposed changes to
+  the *Black* code style.

 
 Documentation for both the current and future styles can be found:
 
 
 Documentation for both the current and future styles can be found: