diff options
| author | Ilya Maximets <i.maximets@ovn.org> | 2020-09-28 04:34:45 +0200 |
|---|---|---|
| committer | Ilya Maximets <i.maximets@ovn.org> | 2020-11-10 02:30:06 +0100 |
| commit | 15177c4dadcc0470cf668cfbd9691d728f5f0721 (patch) | |
| tree | 87578d398bd62f638cd0467c824c45f7695370d3 /Documentation/internals | |
| parent | ed8cf18733fd1f4865d8f16fa06180bf5a772ebe (diff) | |
| download | openvswitch-15177c4dadcc0470cf668cfbd9691d728f5f0721.tar.gz | |
release-process: Add transition period for LTS releases.
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>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Diffstat (limited to 'Documentation/internals')
| -rw-r--r-- | Documentation/internals/release-process.rst | 11 |
1 files changed, 7 insertions, 4 deletions
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 |