| Message ID | 20200928023447.3882969-3-i.maximets@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | New LTS and updted release policy. | expand |
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 --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
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(-)