Clarify that performance improvements are not backported#1826
Clarify that performance improvements are not backported#1826gaborbernat wants to merge 4 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
|
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 |
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.
There was a problem hiding this comment.
If we all agree I can withraw this PR, but I think there's benefit of having this here, as would have saved that discussion thread and initial confusion by someone else.
There was a problem hiding this comment.
I don't think it's obvious that performance improvements are "features", so it's worth clarifying.
There was a problem hiding this comment.
This does not seem to be the place for explaining what features are.
There was a problem hiding this comment.
Perhaps, we should cross link the "feature" explanation location then here? So people can click through and see how we define a feature.
There was a problem hiding this comment.
@StanFromIreland by the way I believe you wanted to link to https://devguide.python.org/developer-workflow/development-cycle/#in-development-main-branch not the committing part, right?
I quoted the section in committing.
There was a problem hiding this comment.
Cross-linking is awkward because that section lists everything main takes, bug fixes included, and bug fixes are the one type that backports without debate. Pointing there to explain what needs discussion sends people to a list where one of the four entries is the opposite case.
I pushed a different fix: the maintenance section now splits changes into low-risk (bug fixes, tests, docs, backport freely) and higher-risk (new features, semantic changes, performance improvements, need a discussion and a strong case first). It names performance improvements directly, so the original confusion can't recur, and it never has to define what a feature is.
There was a problem hiding this comment.
I think this is going the wrong way, and complicating this paragraph. It's goal is to explain what we do and don't backport, not list all the kinds of features. IMO, the note in this paragraph should be something like:
New features should not be backported.
We note features in various places, they shouldn't all have to explain what exactly they are.
There was a problem hiding this comment.
I might be missing something but where do we define that performance improvement is a feature? I know you referenced earlier, but pointed to the opening PR section. The devguide.python.org/developer-workflow/development-cycle#in-development-main-branch specifically calls it out as a separate thing, not as a feature.
We note features in various places, they shouldn't all have to explain what exactly they are.
Explicit better than implicit, I think is better to repeat things (or at least cross link things) rather than let people assume from their knowledge from other locations.
There was a problem hiding this comment.
cross link things) rather than let people assume from their knowledge from other locations.
Yes, that's my idea from above:
I think we should clarify what features are and link here
5 participants
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