Clarify that performance improvements are not backported#1826
Open
gaborbernat wants to merge 3 commits into
Open
Clarify that performance improvements are not backported#1826gaborbernat wants to merge 3 commits into
gaborbernat wants to merge 3 commits into
Conversation
A contributor proposed backporting a performance improvement to the maintenance branches, which prompted core developers to restate the long-standing practice: optimizations are not backported. An optimization can introduce a regression, and a regression in a bugfix release is costly to find and undo. Add this to the maintenance-branch rules so the expectation is explicit, and describe the narrow exception (a clear, no-risk, high-impact change agreed in discussion). Discussion: https://discuss.python.org/t/performance-improvements-and-backports/107625
Documentation build overview
|
skirpichev
reviewed
Jun 5, 2026
Sergey noted the maintenance-branch sentence already reads clearly, so a separate paragraph restates it. Move the performance point into that sentence as one clause and let the existing "rare exceptions ... must be discussed first" line cover the narrow case.
hugovk
changed the title
|
|
||
| The only changes allowed to occur in a maintenance branch without debate are | ||
| bug fixes, test improvements, and edits to the documentation. | ||
| bug fixes, test improvements, and edits to the documentation. Performance |
Member
There was a problem hiding this comment.
I don't really get why "performance improvements" are special here, they are features, and we already explicitly state (albeit elsewhere):
The only branch that receives new features is
main, the in-development branch.
In this event, I think everything generally went according to the docs: can't backport features "without debate," however exceptions can be made, provided you open a discussion first.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A contributor recently proposed backporting a performance improvement to the maintenance branches, and the question surfaced that the devguide does not say whether optimizations should be backported. Core developers confirmed the long-standing practice in the linked discussion: optimizations are not backported, because an optimization can introduce a regression and a regression in a bugfix release is costly to track down and undo.
This adds that rule to the maintenance-branch section of the development cycle, next to the existing "bug fixes, test improvements, and documentation" guidance, and spells out the narrow exception a few core developers noted: a change that is a clear win, carries no regression risk (including for code that subclasses or monkey-patches internals), and matters enough to applications to justify it, discussed first.
Discussion: https://discuss.python.org/t/performance-improvements-and-backports/107625