Clarify development cycle (#1681)

hugovk · AA-Turner · web-flow · commit b24ed5025bb9 · 2025-12-21T11:06:59.000+02:00
Co-authored-by: Adam Turner &lt;9087854+AA-Turner@users.noreply.github.com&gt;
diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst
@@ -68,8 +68,8 @@ Maintenance branches
 A branch for a previous feature release, currently being maintained for bug
 fixes, or for the next feature release in its
 :ref:`beta <beta>` or :ref:`release candidate <rc>` stages.
-There is usually either one or two maintenance branches at any given time for
-Python 3.x.  After the final release of a new minor version (3.x.0), releases
+There are usually either one or two maintenance branches at any given time.
+After the final release of a new minor version (3.x.0), releases
 produced from a maintenance branch are called **bugfix** or **maintenance**
 releases; the terms are used interchangeably. These releases have a
 **micro version** number greater than zero.
@@ -190,7 +190,7 @@ severe enough (for example, crashes) that they deserve fixing before the final r
 All other issues should be deferred to the next development cycle, since
 stability is the strongest concern at this point.
 
-While the goal is to have no code changes between a RC and a final release,
+While the goal is to have no code changes between an RC and a final release,
 there may be a need for final documentation or test fixes. Any such proposed
 changes should be discussed first with the release manager.
 
@@ -204,8 +204,7 @@ Final
 ^^^^^
 
 When a final release is being cut, only the release manager (RM) can make
-changes to the branch.  After the final release is published, the full
-:ref:`development cycle <stages>` starts again for the next minor version.
+changes to the branch.
 
 
 Repository administration
