On 9/2/20 5:03 PM, Stokes, Ian 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. > > 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.
In this scheme 2.12 will be supported for an extra 6 months. It's hard, actually, to fully align this process with DPDK release schedule and, yes, there is no clear reason to do that. > >> >> 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
