[ovs-dev] [PATCH RFC 2/2] release-process: LTS transition period and policy for unmaintained branches.
Flavio Leitner
fbl at sysclose.org
Fri Aug 28 13:55:37 UTC 2020
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.
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.
--
fbl
More information about the dev
mailing list