On 8/28/20 3:55 PM, Flavio Leitner wrote: > On Tue, Aug 25, 2020 at 02:24:11PM +0200, Ilya Maximets wrote: >> 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 <i.maxim...@ovn.org> >> --- >> .../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. > > Thanks for working on this. I think the last paragraph is not much > clear, because one can think that branches in between LTS and latest > might not receive all bug fixes and then there would be regressions > updating from LTS to one of them.
I think that is exactly what current documentation says. FAQ says [1]: "Releases that are not LTS may not be fixed and may just be supplanted by the next major release." [1] https://docs.openvswitch.org/en/latest/faq/releases/ Before this change (now) we had 2 formally maintained branches (LTS and latest). And there is no any guarantee that branches in-between receives any bug fixes and we're formally not obligated to provide any releases on these branches. After this change we're taking responsibility to provide releases for last 4 releases, but we're still not obligated to backport every bug fix. I understand that this is a bit confusing and not very convenient for users of these branches, but it is, at least, something. IMHO, upgrades from LTS to non-LTS doesn't make much sense from the possible regressions perspective, unless it's an upgrade to latest stable. With new strategy users will have 1 release time frame to upgrade from the previous LTS to new LTS. In case we will nominate LTS to move to current stable at the end of its support cycle, users will have 1 year (0.5 for stable + 0.5 for LTS transition) in order to upgrade, e.g. 1. 2.17 released on Feb 2022 --> new stable 2. 2.18 released on Aug 2022 --> new stable 2.17 nominated to be an LTS at the same time Transition period started for 2.13 (old LTS). 3. 2.19 released on Feb 2023 --> new stable Dropped support for 2.13 due to end of the transition period. In this scenario 2.17 will be continuously supported for 1 year at the moment 2.13 becomes unmaintained. This should be enough time frame for users to upgrade. We might want to formalize this process, though. Maybe something like this: """ At most three release branches are formally maintained at any given time: the latest release, the latest release designed as LTS and a previous LTS release during the transition period. 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 major release after the new LTS is chosen. This one release time frame is a transition period which is intended for users to upgrade from old LTS to new one. New LTS release is chosen every 2 years. The process is that current latest stable release becomes an LTS release at the same time with the next major release. 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 skipping designation of the next LTS release occurs on the OVS development mailing list. LTS designation schedule example (depends on current state of development): 2.14 released on Aug 2020 - new latest stable, 2.13 stable --> new LTS 2.15 released on Feb 2021 - new latest stable, 2.5 LTS --> EOL 2.16 released on Aug 2021 - new latest stable 2.17 released on Feb 2022 - new latest stable 2.18 released on Aug 2022 - new latest stable, 2.17 stable --> new LTS 2.19 released on Feb 2023 - new latest stable, 2.13 LTS --> EOL 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. """ The main difference here is that we're specifying that LTS nominated every 2 years by default and "skipping" should be discussed on a list instead of "choosing". And also specified the process that new LTS is a previous stable, so the branch is already maintained for 6 months before becoming an LTS and there is no unmaintained time for this branch until its EOL. What do you think? Simon, Ian, anyone else? Best regards, Ilya Maximets. > > Perhaps: > However, stable branches older than LTS include only bug fixes that > are easy to backport, i.e. might not include all the fixes that LTS > has. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
