[ovs-dev] [PATCH v2 3/4] release-process: Standardize designation of new LTS releases.

[Ilya Maximets]

Standardize that we will mark a new release as LTS every two years
to avoid situation where we have a really old LTS branch that no-one
actually uses, but we have to support and provide releases for it.

This will also make release process more predictable, so users will
be able to rely on it and plan their upgrades accordingly.

As a bonus, 2 years support cycle kind of aligns with 2 years support
cycle of DPDK LTS releases.

Still keeping a window for us to discuss and avoid marking some
particular release as LTS in case of significant issues with it.

Signed-off-by: Ilya Maximets <i.maximets at ovn.org>
---
 Documentation/internals/release-process.rst | 32 +++++++++++++++++----
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
index 6352af0dc..8a655b33b 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -82,12 +82,32 @@ 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.
-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.
+
+New LTS release is chosen every 2 years.  The process is that current latest
+stable release becomes an LTS release at the same time the next major release
+is out.  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):
+
++---------+--------------+--------------------------------------------------+
+| Version | Release Date | Actions                                          |
++---------+--------------+--------------------------------------------------+
+| 2.14    | Aug 2020     | 2.14 - new latest stable, 2.13 stable ⟶ new LTS  |
++---------+--------------+--------------------------------------------------+
+| 2.15    | Feb 2021     | 2.12 - new latest stable, 2.5  LTS ⟶ EOL         |
++---------+--------------+--------------------------------------------------+
+| 2.16    | Aug 2021     | 2.16 - new latest stable                         |
++---------+--------------+--------------------------------------------------+
+| 2.17    | Feb 2022     | 2.17 - new latest stable                         |
++---------+--------------+--------------------------------------------------+
+| 2.18    | Aug 2022     | 2.18 - new latest stable, 2.17 stable ⟶ new LTS  |
++---------+--------------+--------------------------------------------------+
+| 2.19    | Feb 2023     | 2.19 - new latest stable, 2.13 LTS ⟶ EOL         |
++---------+--------------+--------------------------------------------------+
 
 Release Numbering
 -----------------
-- 
2.25.4