ref-manual: release-process: update for LTS releases

(From yocto-docs rev: 145488ac9ee4ad5efb0966f07ff5e7ff804f6562)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>

1 files changed, 56 insertions, 22 deletions

diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst
index 8acb4b8e09..d376d51bd2 100644
--- a/documentation/ref-manual/release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -18,9 +18,9 @@ Following are examples of some major YP releases with their codenames
 also shown. See the ":ref:`ref-manual/release-process:major release codenames`"
 section for information on codenames used with major releases.
 
-  - 2.2 (Morty) 
-  - 2.1 (Krogoth)
-  - 2.0 (Jethro) 
+  - 4.1 ("Langdale")
+  - 4.0 ("Kirkstone")
+  - 3.4 ("Honister")
 
 While the cadence is never perfect, this timescale facilitates
 regular releases that have strong QA cycles while not overwhelming users
@@ -32,9 +32,9 @@ basis and are usually driven by the accumulation of enough significant
 fixes or enhancements to the associated major release. Following are
 some example past point releases:
 
-  - 2.1.1
-  - 2.1.2
-  - 2.2.1 
+  - 4.1.3
+  - 4.0.8
+  - 3.4.4
 
 The point release
 indicates a point in the major release branch where a full QA cycle and
@@ -87,15 +87,51 @@ stable release.
    exception to this policy occurs when there is a strong reason such as
    the fix happens to also be the preferred upstream approach.
 
-Stable release branches have strong maintenance for about a year after
-their initial release. Should significant issues be found for any
-release regardless of its age, fixes could be backported to older
-releases. For issues that are not backported given an older release,
-Community LTS trees and branches allow community members to share
-patches for older releases. However, these types of patches do not go
-through the same release process as do point releases. You can find more
-information about stable branch maintenance at
-:yocto_wiki:`/Stable_branch_maintenance`.
+.. _ref-long-term-support-releases:
+
+Long Term Support Releases
+==========================
+
+While stable releases are supported for a duration of seven months,
+some specific ones are now supported for a longer period by the Yocto
+Project, and are called Long Term Support (:term:`LTS`) releases.
+
+When significant issues are found, :term:`LTS` releases allow to publish
+fixes not only for the current stable release, but also to the
+:term:`LTS` releases that are still supported. Older stable releases which
+have reached their End of Life (EOL) won't receive such updates.
+
+This started with version 3.1 ("Dunfell"), released in April 2020, which
+the project initially committed to supporting for two years, but this duration
+was later extended to four years. Similarly, the following :term:`LTS` release,
+version 4.0 ("Kirkstone"), was released two years later in May 2022 and the
+project committed to supporting it for four years too.
+
+Therefore, a new :term:`LTS` release is made every two years and is supported
+for four years. This offers more stability to project users and leaves more
+time to upgrade to the following :term:`LTS` release.
+
+See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management
+of stable and :term:`LTS` releases.
+
+.. image:: svg/releases.*
+   :width: 100%
+
+.. note::
+
+   In some circumstances, a layer can be created by the community in order to
+   add a specific feature or support a new version of some package for an :term:`LTS`
+   release. This is called a :term:`Mixin` layer. These are thin and specific
+   purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific
+   feature into that build. These are created on an as-needed basis and
+   maintained by the people who need them.
+
+   Policies on testing these layers depend on how widespread their usage is and
+   determined on a case-by-case basis. You can find some :term:`Mixin` layers in the
+   :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto
+   Project provides hosting for those repositories, it does not provides
+   testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider
+   community.
 
 Testing and Quality Assurance
 =============================
@@ -155,14 +191,12 @@ effort has been made to automate the tests so that more people can use
 them and the Yocto Project development team can run them faster and more
 efficiently.
 
-The Yocto Project's main Autobuilder (&YOCTO_AB_URL;)
-publicly tests each Yocto Project release's code in the
-:term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
-occurs for both the current state of the "master" branch and also for
+The Yocto Project's main Autobuilder (&YOCTO_AB_URL;) publicly tests each Yocto
+Project release's code in the :oe_git:`openembedded-core </openembedded-core>`,
+:yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The
+testing occurs for both the current state of the "master" branch and also for
 submitted patches. Testing for submitted patches usually occurs in the
-"ross/mut" branch in the ``poky-contrib`` repository (i.e. the
-master-under-test branch) or in the "master-next" branch in the ``poky``
-repository.
+in the "master-next" branch in the :yocto_git:`poky </poky>` repository.
 
 .. note::