This is based on discussions that have happened both on the ovs-dev mailing list as well as public IRC developer meetings.
Signed-off-by: Mark Michelson <[email protected]> --- .../contributing/backporting-patches.rst | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst index d7e4522cf..a633fb7db 100644 --- a/Documentation/internals/contributing/backporting-patches.rst +++ b/Documentation/internals/contributing/backporting-patches.rst @@ -73,6 +73,88 @@ not a trivial cherry-pick, then the maintainer may opt to submit the backport for the older branch on the mailing list for further review. This should be done in the same manner as described above. +Supported Versions +~~~~~~~~~~~~~~~~~~ + +As documented in :doc:`release-process`, standard term support versions receive +regular releases for a year, and LTS versions receive regular releases for two +years, plus an additional year of critical and security fixes. + +To make things easy, maintainers should simply backport all bugfixes to the +previous four branches before main. This is guaranteed to get the fix into all +supported standard-support versions as well as the current LTS version. This +will mean that maintainers will backport bugfixes to branches representing +versions that are not currently supported. + +Critical and security fixes should be handled differently. Maintainers should +determine what is the oldest LTS version that currently is supported for +critical and security fixes. Maintainers should backport these fixes to all +branches between main and that LTS version. This will mean that maintainers +will backport critical and security fixes into branches representing versions +that are not currently supported. + +The reason for backporting fixes into unsupported versions is twofold: + +- Backporting bugfixes into unsupported versions likely makes it easier to + backport critical and security fixes into older versions when necessary. +- Backporting critical and security fixes into unsupported versions allows for + users that are not ready to upgrade to a supported version to continue using + the branch tip until they are ready to fully upgrade. + +Example ++++++++ + +Consider the following release timeline. + ++---------+----------+--------------+ +| Version | Date | Release Type | ++---------+----------+--------------+ +| 24.03 | Mar 2024 | LTS | ++---------+----------+--------------+ +| 24.09 | Sep 2024 | Standard | ++---------+----------+--------------+ +| 25.03 | Mar 2025 | Standard | ++---------+----------+--------------+ +| 25.09 | Sep 2025 | Standard | ++---------+----------+--------------+ +| 26.03 | Mar 2026 | LTS | ++---------+----------+--------------+ +| 26.09 | Sep 2026 | Standard | ++---------+----------+--------------+ + +In our hypothetical world it is October 2026, so the current status of each +release is: + ++---------+------------------------------+ +| Version | Support Status | ++---------+------------------------------+ +| 24.03 | Critical/Security fixes only | ++---------+------------------------------+ +| 24.09 | Unsupported since Sep 2025 | ++---------+------------------------------+ +| 25.03 | Unsupported since Mar 2026 | ++---------+------------------------------+ +| 25.09 | Unsupported since Sep 2026 | ++---------+------------------------------+ +| 26.03 | Supported | ++---------+------------------------------+ +| 26.09 | Supported | ++---------+------------------------------+ + +Let's say that a bug fix is committed to main. Our policy would be to backport +the fix to 26.09, 26.03, 25.09, and 25.03. The fix will eventually appear in +releases of 26.03 and 26.09. Even though the fix is in the development branches +for 25.03 and 25.09, the fix will never appear in a release. + +Now let's say that a security issue is committed to main. Our policy would be +to backport the fix to 24.03, 24.09, 25.03, 25.09, 26.03, and 26.09. 24.03 is +the oldest LTS version that still is receiving critical and security fixes, so +we backport the fix to all branches between main and that version. The security +fix will appear in releases of 24.03, 26.03, and 26.09. The security fix will +be present in the 24.09, 25.03, and 25.09 development branches, but will never +appear in a release. + + Submission ~~~~~~~~~~ -- 2.39.2 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
