> 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.
Thanks for proposing this Ilya, few comments inline. > > 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. > +1, I think we saw this in the past few months where there was a build up of patches on the older branches without a release, it seems to be the practice to date so makes sense to formalize as you have here. > 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. Just to confirm, do you propose that OVS 2.12 would also have its last stable release at the same time as 2.11 as both use DPDK 18.11? Or would 2.12 be supported long by the nature that it's 1 release newer than 2.11? >From a DPDK point of view probably makes sense to finish the 2.11 and 2.12 >support at the same time but I'm aware that DPDK may not be the only factor to >consider here. > > 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. > Above generally looks good to me, I think it's formalizing the process which is great to see. Thanks Ian > Release Numbering > ----------------- > -- > 2.25.4 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
