On Wed, Jan 12, 2022 at 1:35 PM Mark Michelson <[email protected]> wrote: > > OVN LTS releases have a lot of ambiguity, so this is intended to codify > LTS support and cadence. > > Signed-off-by: Mark Michelson <[email protected]> > --- > Documentation/internals/release-process.rst | 28 +++++++++++++-------- > 1 file changed, 18 insertions(+), 10 deletions(-) > > diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst > index f37c09e51..1ad43f3cc 100644 > --- a/Documentation/internals/release-process.rst > +++ b/Documentation/internals/release-process.rst > @@ -75,16 +75,24 @@ Scheduling`_ for the timing of each stage: > 2019.10.2, 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 OVN project has designated as being maintained for a longer period of > -time. Currently, an LTS release is maintained until the next LTS is chosen. > -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 OVN 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. > +Long-term Support Releases > +-------------------------- > + > +The OVN project will periodically designate a release as "long-term support" or > +LTS for short. An LTS release has the distinction of being maintained for > +longer than a standard release. > + > +LTS releases will receive bug fixes until the point that another LTS is > +released. At that point, the old LTS will receive an additional year of > +critical and security fixes. Critical fixes are those that are required to > +ensure basic operation (e.g. memory leak fixes, crash fixes). Security fixes > +are those that address concerns about exploitable flaws in OVN and that have a > +corresponding CVE report. > + > +LTS releases are scheduled to be released once every three years. This means > +that any given LTS will receive bug fix support for three years, followed by > +one year of critical bug fixes and security fixes. > +
Thanks Mark. It is great to have a clear timeline of the LTS releases. Just a little concern about the 3 + 1 cycle. Firstly it may be a big burden for maintainers to maintain branches up to 4 years old, even if it is for bug fixes only. We need to consider bug reproduction and debugging, too, if some bugs are reported on the old LTS branch but not the newer branches. Secondly, it doesn't seem to be very valuable to maintain branches so old. I understand that people would choose to do minor upgrades for just bug fixes without worrying about compatibility and other problems incurred by a major release change, but cloud-infrastructure changes fast. A major upgrade in 2 years sounds already very long. Thirdly, the frequency of LTS release every 3 years may be also too low. Some user may want to use LTS releases only, so at the 2 year point, they can either choose the last 2-year old branch which may not have the features they need, or will have to wait another year for the next LTS. Would 1 + 1 (LTS once every year, and 2 latest LTS releases be maintained, meaning each LTS's life is 2 years) be better? Or, to match the ubuntu LTS cycle, 2 + 1? Thanks, Han > > Release Numbering > ----------------- > -- > 2.31.1 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
