diff mbox series

[ovs-dev,v2,2/4] release-process: Add transition period for LTS releases.

Message ID 20200928023447.3882969-3-i.maximets@ovn.org
State New
Headers show
Series New LTS and updted release policy. | expand

Commit Message

Ilya Maximets Sept. 28, 2020, 2:34 a.m. UTC
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.

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 many
fixes there)

Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 Documentation/internals/release-process.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Comments

Flavio Leitner Oct. 6, 2020, 8:28 p.m. UTC | #1
On Mon, Sep 28, 2020 at 04:34:45AM +0200, Ilya Maximets wrote:
> 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.
> 
> 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 many
> fixes there)

I think you jinxed it with that last phrase. :-)


> 
> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
> ---

Acked-by: Flavio Leitner <fbl@sysclose.org>
diff mbox series

Patch

diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
index 63080caab..6352af0dc 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -75,10 +75,13 @@  Scheduling`_ for the timing of each stage:
    and so on.  The process is the same for these additional release as for a .0
    release.
 
-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.
+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.
 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