diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index 935f26653a..9ba4067505 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -77,10 +77,21 @@ releases; the terms are used interchangeably. These releases have a **micro version** number greater than zero. The only changes allowed to occur in a maintenance branch without debate are -bug fixes. Also, a general rule for maintenance branches is that compatibility +bug fixes. Also, a general rule for maintenance branches is that compatibility must not be broken at any point between sibling micro releases (3.5.1, 3.5.2, -etc.). For both rules, only rare exceptions are accepted and **must** be -discussed first. +etc.). For both rules, only rare exceptions are accepted and **must** be +discussed first. Among the rare exceptions to the rules of bug fixes and compatibility, +backporting of documentation and tests is encouraged. + +Backporting serves dual purposes. First, it increases the visibility of +documentation changes since most users refer to stable versions at +`docs.python.org/3/ `_ rather +than the `docs.python.org/dev/ `_ documentation. +Second, it minimizes conflicts for future bugfix backports. + +Backporting should target enhancements in documentation and tests for +currently **stable** versions, specifically branches in a **bugfix** release cycle +or higher. A new maintenance branch is normally created when the next feature release cycle reaches feature freeze, i.e. at its first beta pre-release. diff --git a/versions.rst b/versions.rst index b712dfc6e3..e06990deb8 100644 --- a/versions.rst +++ b/versions.rst @@ -50,7 +50,8 @@ Status key but new source-only versions can be released :end-of-life: release cycle is frozen; no further changes can be pushed to it. -See also the :ref:`devcycle` page for more information about branches. +See also :ref:`devcycle` for branch information and :ref:`maintbranch` for details on +backporting documentation and test changes above the **bugfix** level. By default, the end-of-life is scheduled 5 years after the first release, but can be adjusted by the release manager of each branch. All Python 2