Skip to content

Clarify development cycle #1681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hugovk wants to merge 3 commits into
base: main
Choose a base branch
from
+4 −5
Open

Clarify development cycle #1681

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1e39761
It's always Python 3.x
hugovk Nov 5, 2025
2b5060b
a RC -> an RC
hugovk Nov 5, 2025
270131a
After a final is published in October, the dev cycle for the next min…
hugovk Nov 5, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions developer-workflow/development-cycle.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 is usually either one or two maintenance branches at any given time.
Copy link
Member

@AA-Turner AA-Turner Dec 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are ... branches, rather than 'is':

Suggested change
There is usually either one or two maintenance branches at any given time.
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
Comment on lines +71 to +72
Copy link
Member Author

@hugovk hugovk Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's always Python 3.x, we don't care about 2.x any more.

If there's a 4.x, and things change, we'll update it then.

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.
Expand Down Expand Up @@ -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.

Expand All @@ -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.
Comment on lines -207 to -208
Copy link
Member Author

@hugovk hugovk Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incorrect.

After the final release is published in October, the dev cycle for the next one had already started back in May.

Copy link
Member

@AA-Turner AA-Turner Dec 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add that this period starts after RC1? Or at least it has for the last couple of releases.

changes to the branch.


Repository administration
Expand Down
Loading