While only 2 branches are formally maintained (LTS and latest release), OVS team usually provides stable releases for other branches too, at least for branches between LTS and latest.
While LTS change happens, according to release-process.rst, we're immediately dropping support for the old LTS and, according to backporting-patches.rst could stop backporting bug fixes to branches older than new LTS. While this might be OK for an upstream project (some upstream projects like QEMU doesn't support anything at all except the last release) it doesn't sound like a user-friendly policy. Below addition to the release process might make the process a bit smoother in terms that we will continue support of branches a little bit longer even after changing current LTS, i.e. providing at least a minimal transition period (1 release frame) for users of old LTS. We will also not drop support for not so old branches even after the transition period if committers will follow the "as far as it goes" backporting policy. Still keeping the room for us to not backport disruptive changes or changes that are hard to maintain or OVN related fixes anywhere but LTS and the latest released branch. After 2 year period (4 releases) committers are still free to backport fixes they think are needed on older branches, however we will likely not provide actual releases on these branches, unless it's specially requested and discussed. Effectively, this change means that we will support branch-2.5 until 2.15 release, i.e. we will provide the last release, if any, on branch-2.5 somewhere around Feb 2021. (I don't actually expect much fixes there) And, presumably, at the same time we will provide last releases for branch 2.11 and below, if needed. Additionally, "4 releases" policy aligns with the DPDK LTS support policy, i.e. we will be able to validate and release last OVS releases with the last available DPDK LTS, e.g. OVS 2.11 last stable release will likely be released with the 18.11 EOL release validated. Signed-off-by: Ilya Maximets <[email protected]> --- .../contributing/backporting-patches.rst | 3 ++- Documentation/internals/release-process.rst | 21 ++++++++++++------- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst index e8f4f271c..162e9d209 100644 --- a/Documentation/internals/contributing/backporting-patches.rst +++ b/Documentation/internals/contributing/backporting-patches.rst @@ -69,7 +69,8 @@ targeted to the `master` branch, using the ``Fixes`` tag described in :doc:`submitting-patches`. The maintainer first applies the patch to `master`, then backports the patch to each older affected tree, as far back as it goes or at least to all currently supported branches. This is usually each branch back -to the most recent LTS release branch. +to the oldest maintained LTS release branch or the last 4 release branches if +the oldest LTS is newer. If the fix only affects a particular branch and not `master`, contributors should submit the change with the target branch listed in the subject line of diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst index 63080caab..c5475c49b 100644 --- a/Documentation/internals/release-process.rst +++ b/Documentation/internals/release-process.rst @@ -78,13 +78,20 @@ Scheduling`_ for the timing of each stage: At most two release branches are formally maintained at any given time: the latest release and the latest release designed as LTS. An LTS release is one that the OVS project has designated as being maintained for a longer period of -time. Currently, an LTS release is maintained until the next LTS is chosen. -There is not currently a strict guideline on how often a new LTS release is -chosen, but so far it has been about every 2 years. That could change based on -the current state of OVS development. For example, we do not want to designate -a new release as LTS that includes disruptive internal changes, as that may -make it harder to support for a longer period of time. Discussion about -choosing the next LTS release occurs on the OVS development mailing list. +time. Currently, an LTS release is maintained until the next major release +after the new LTS is chosen. There is not currently a strict guideline on how +often a new LTS release is chosen, but so far it has been about every 2 years. +That could change based on the current state of OVS development. For example, +we do not want to designate a new release as LTS that includes disruptive +internal changes, as that may make it harder to support for a longer period of +time. Discussion about choosing the next LTS release occurs on the OVS +development mailing list. + +While branches other than LTS and the latest release are not formally +maintained, the OVS project usually provides stable releases for these branches +for at least 2 years, i.e. stable releases are provided for the last 4 +release branches. However, these branches includes only bug fixes that are +easy to backport, i.e. might not include all the fixes that LTS has. Release Numbering ----------------- -- 2.25.4 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
