From b387c9b1d6d170a98146dbcd654842d688e7e48c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bern=C3=A1t=20G=C3=A1bor?= Date: Thu, 4 Jun 2026 19:53:47 -0700 Subject: [PATCH 1/4] =?UTF-8?q?=F0=9F=93=9D=20docs:=20clarify=20optimizati?= =?UTF-8?q?ons=20are=20not=20backported?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- developer-workflow/development-cycle.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index af198a4007..dfe69ba120 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -81,6 +81,13 @@ 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. +Performance improvements are not backported. An optimization can introduce a +regression, and a regression shipped in a maintenance release is painful to +track down and undo, so optimizations remain on the ``main`` branch. A backport +is a rare exception, reserved for a clear win that carries no regression risk +(including for code that subclasses or monkey-patches internals) and matters +enough to applications to justify it, and it **must** be discussed first. + Backporting changes reduces the risk of future conflicts. For documentation, it increases the visibility of improvements, since most readers access the `stable documentation `__ From d1612a0bd402237ad530bae68ab59e2ffec8224d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bern=C3=A1t=20G=C3=A1bor?= Date: Thu, 4 Jun 2026 21:22:38 -0700 Subject: [PATCH 2/4] =?UTF-8?q?=F0=9F=93=9D=20docs:=20fold=20performance?= =?UTF-8?q?=20note=20into=20existing=20rule?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- developer-workflow/development-cycle.rst | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index dfe69ba120..88ffb36d65 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -75,19 +75,14 @@ releases; the terms are used interchangeably. These releases have a **micro version** number greater than zero. 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 +improvements are not among them: an optimization can introduce a regression, +and a regression in a maintenance release is painful to track down and undo. 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. -Performance improvements are not backported. An optimization can introduce a -regression, and a regression shipped in a maintenance release is painful to -track down and undo, so optimizations remain on the ``main`` branch. A backport -is a rare exception, reserved for a clear win that carries no regression risk -(including for code that subclasses or monkey-patches internals) and matters -enough to applications to justify it, and it **must** be discussed first. - Backporting changes reduces the risk of future conflicts. For documentation, it increases the visibility of improvements, since most readers access the `stable documentation `__ From 23c01536fb041141575af08ed83e865172902398 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bern=C3=A1t=20G=C3=A1bor?= Date: Thu, 4 Jun 2026 21:30:34 -0700 Subject: [PATCH 3/4] =?UTF-8?q?=F0=9F=94=A7=20chore:=20re-trigger=20Read?= =?UTF-8?q?=20the=20Docs=20build?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From 19ac73f6a9313793953efc20cf6a0348e84f73cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bern=C3=A1t=20G=C3=A1bor?= Date: Fri, 5 Jun 2026 07:22:56 -0700 Subject: [PATCH 4/4] =?UTF-8?q?=F0=9F=93=9D=20docs:=20group=20maintenance?= =?UTF-8?q?=20backports=20by=20risk?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- developer-workflow/development-cycle.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index 88ffb36d65..ea46c2405f 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -74,14 +74,15 @@ 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. -The only changes allowed to occur in a maintenance branch without debate are -bug fixes, test improvements, and edits to the documentation. Performance -improvements are not among them: an optimization can introduce a regression, -and a regression in a maintenance release is painful to track down and undo. +Changes backported to a maintenance branch fall into two groups. *Low-risk* +changes (bug fixes, test improvements, and documentation edits) may be +backported without debate. *Higher-risk* changes (new features, semantic +changes, and performance improvements) can introduce regressions, so they are +not backported as a matter of course. 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. +etc.). For both rules, only rare exceptions are accepted, and each requires a +strong case agreed upon in discussion beforehand. Backporting changes reduces the risk of future conflicts. For documentation, it increases the visibility of improvements,