From 9e91c4537985ed3bc6fbd03bdcf6cc6f324555ab Mon Sep 17 00:00:00 2001 From: Jacob Coffee Date: Wed, 27 Sep 2023 20:31:43 -0500 Subject: [PATCH] fix(docs): apply suggestions --- developer-workflow/development-cycle.rst | 9 ++++----- versions.rst | 3 +-- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index 9ba4067505..f13bbaa060 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -77,11 +77,10 @@ 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 -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. Among the rare exceptions to the rules of bug fixes and compatibility, -backporting of documentation and tests is encouraged. +bug fixes and the backporting of documentation and tests. 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. Backporting serves dual purposes. First, it increases the visibility of documentation changes since most users refer to stable versions at diff --git a/versions.rst b/versions.rst index e06990deb8..6ca0d440d6 100644 --- a/versions.rst +++ b/versions.rst @@ -50,8 +50,7 @@ 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 :ref:`devcycle` for branch information and :ref:`maintbranch` for details on -backporting documentation and test changes above the **bugfix** level. +See also the :ref:`devcycle` page for more information about branches and backporting. 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