The only changes allowed to occur in a maintenance branch without debate are bug fixes, test improvements, and edits to the documentation. Also, a general rule for maintenance branches is that compatibility must not be broken at any point between sibling micro releases (3.12.1, 3.12.2, etc.). For both rules, only rare exceptions are accepted and must be discussed first.
I just merged a small change in main which is a performance improvement with no changes to the public API. I added “needs backport” labels and backport PRs have been generated, but @Stanfromireland pointed out the above text from the devguide. Does this specific change seem reasonable to backport to 3.13, 3.14 and 3.15? Feedback gratefully received!
In general we don’t. But when they are clear wins and no risk (even to code doing things like subclassing & mucking with private APIs, or monkeypatching) and meaningfully important to applications I think it is fair to backport. Just broaden your imagination as to what code may be doing that counts as risk when it comes to backport decisions.
This particular small change doesn’t have that importance feel to me so I wouldn’t bother.
I never backport optimizations. If the optimization introduces a regression, it’s really a pain to have it in a 3.x.y bugfix release I don’t recall any optimization which was important enough to be backported. I was bitten too often by regressions when fixing bugs.
I opened a devguide PR to write this down so the expectation is discoverable: 📝 docs: clarify that performance improvements are not backported by gaborbernat · Pull Request #1826 · python/devguide · GitHub. It states that performance improvements are not backported (an optimization can introduce a regression, and a regression in a bugfix release is costly to track down and undo), and notes the narrow exception Gregory described: a clear win with no regression risk, including for code that subclasses or monkey-patches internals, that matters enough to applications to justify it, discussed first.
Thanks for the input here, happy to adjust the wording if the framing of the exception should be tighter or looser.
I don’t recall any optimization which was important enough to be backported. I was bitten too often by regressions when fixing bugs.