| Message ID | 20200928023447.3882969-5-i.maximets@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | New LTS and updted release policy. | expand |
On Mon, Sep 28, 2020 at 04:34:47AM +0200, Ilya Maximets wrote: > While only 2 branches are formally maintained (LTS and latest release), > OVS team usually provides stable releases for other branches too, at > least for branches between LTS and latest. > > When transition period ends for an old LTS, we, 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 > it doesn't sound like a user-friendly policy just because it means > that we're dropping support for branches released less than a year > ago. > > Below addition to the release process might make the process a bit > smoother in terms that we will not drop support for not so old branches > even after the transition period, if committers will follow the > "as far as it goes" backporting policy. And we will provide stable > releases for these branches for at least 2 years (these releases could > be less frequent than releases on LTS branches). > > After 2 year period (4 releases) committers are still free to backport > fixes they think are needed on older branches, however we will likely > not provide actual releases on these branches, unless it's specially > requested and discussed. > > Additionally, "4 releases" policy aligns with the DPDK LTS support > policy, i.e. we will be able to validate and release last OVS releases > with the last available DPDK LTS, e.g. OVS 2.11 last stable release > will likely be released with the 18.11 EOL release validated. > > Signed-off-by: Ilya Maximets <i.maximets@ovn.org> > --- Thanks for adding the possibility for developers to provide a backport fix. Acked-by: Flavio Leitner <fbl@sysclose.org>
diff --git a/Documentation/internals/contributing/backporting-patches.rst b/Documentation/internals/contributing/backporting-patches.rst index e8f4f271c..162e9d209 100644 --- a/Documentation/internals/contributing/backporting-patches.rst +++ b/Documentation/internals/contributing/backporting-patches.rst @@ -69,7 +69,8 @@ targeted to the `master` branch, using the ``Fixes`` tag described in :doc:`submitting-patches`. The maintainer first applies the patch to `master`, then backports the patch to each older affected tree, as far back as it goes or at least to all currently supported branches. This is usually each branch back -to the most recent LTS release branch. +to the oldest maintained LTS release branch or the last 4 release branches if +the oldest LTS is newer. If the fix only affects a particular branch and not `master`, contributors should submit the change with the target branch listed in the subject line of diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst index 8a655b33b..fb39ccb5d 100644 --- a/Documentation/internals/release-process.rst +++ b/Documentation/internals/release-process.rst @@ -109,6 +109,15 @@ LTS designation schedule example (depends on current state of development): | 2.19 | Feb 2023 | 2.19 - new latest stable, 2.13 LTS ⟶ EOL | +---------+--------------+--------------------------------------------------+ +While branches other than LTS and the latest release are not formally +maintained, the OVS project usually provides stable releases for these branches +for at least 2 years, i.e. stable releases are provided for the last 4 +release branches. However, these branches may not include all the fixes that +LTS has in case backporting is not straightforward and developers are not +willing to spend their time on that (this mostly affects branches that are +older than the LTS, because backporting to LTS implies backporting to all +intermediate branches). + Release Numbering -----------------
While only 2 branches are formally maintained (LTS and latest release), OVS team usually provides stable releases for other branches too, at least for branches between LTS and latest. When transition period ends for an old LTS, we, 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 it doesn't sound like a user-friendly policy just because it means that we're dropping support for branches released less than a year ago. Below addition to the release process might make the process a bit smoother in terms that we will not drop support for not so old branches even after the transition period, if committers will follow the "as far as it goes" backporting policy. And we will provide stable releases for these branches for at least 2 years (these releases could be less frequent than releases on LTS branches). After 2 year period (4 releases) committers are still free to backport fixes they think are needed on older branches, however we will likely not provide actual releases on these branches, unless it's specially requested and discussed. Additionally, "4 releases" policy aligns with the DPDK LTS support policy, i.e. we will be able to validate and release last OVS releases with the last available DPDK LTS, e.g. OVS 2.11 last stable release will likely be released with the 18.11 EOL release validated. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> --- .../internals/contributing/backporting-patches.rst | 3 ++- Documentation/internals/release-process.rst | 9 +++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)