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

Simon Horman simon.horman at netronome.com
Tue Sep 1 12:00: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>

This also sounds reasonable to me but I don't feel that I am in a position
to sign off on it.

Reviewed-by: Simon Horman <simon.horman at netronome.com>

Do you, as a follow-up, plan to open a discussion on formalising the
LTS selection process?


More information about the dev mailing list