release-process: Policy for unmaintained branches.

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.

When transition period ends for an old LTS, we, 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
it doesn't sound like a user-friendly policy just because it means
that we're dropping support for branches released less than a year
ago.

Below addition to the release process might make the process a bit
smoother in terms that we will 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.  And we will provide stable
releases for these branches for at least 2 years (these releases could
be less frequent than releases on LTS branches).

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.

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 <[email protected]>
Acked-by: Flavio Leitner <[email protected]>
Acked-by: Kevin Traynor <[email protected]>

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

Documentation/internals/release-process.rst

@@ -109,6 +109,15 @@ LTS designation schedule example (depends on current state of development):
 | 2.19    | Feb 2023     | 2.19 - 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 may not include all the fixes that
+LTS has in case backporting is not straightforward and developers are not
+willing to spend their time on that (this mostly affects branches that are
+older than the LTS, because backporting to LTS implies backporting to all
+intermediate branches).
+
 Release Numbering
 -----------------