[ovs-dev] [PATCH RFC 2/2] release-process: LTS transition period and policy for unmaintained branches.

[Flavio Leitner]

On Thu, Sep 03, 2020 at 04:20:53PM +0200, Ilya Maximets wrote:
> 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.maximets at 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?

The issue I see is that the idea of "easy to backport" is
subjective. If one is available to do a backport work,
would that be acceptable?

Otherwise it sounds good to me.

fbl

> 
> 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.
> > 
>