diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst
index fa057e0..2ffbd93 100644
--- a/poky/documentation/ref-manual/release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -18,9 +18,9 @@
 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 @@
 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,33 +87,53 @@
    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.
+
+This started with version 3.1 ("Dunfell"), released in April 2020, that
+the project committed to supporting until the next :term:`LTS` release was out.
+This next :term:`LTS` release, version 4.0 ("Kirkstone"), was released in May 2022
+and offered with two years of support too.
+
+However, as an experiment, support for "Dunfell" was extended to four years, until
+April 2024, therefore offering more stability to projects and leaving more time
+to upgrade to the latest :term:`LTS` release. The project hasn't made any commitment to
+extending "Kirkstone" support too, as this will also depend on available funding
+for such an effort.
+
+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.
+
+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 LTS
-   release.  This is called a "mixin" layer. These are thin and specific
-   purpose layers which can be stacked with an LTS release to "mix" a specific
+   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 "mixin" layers in the
+   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 "mixin" layers may be released elsewhere by the wider
+   testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider
    community.
 
-
 Testing and Quality Assurance
 =============================
 
@@ -161,25 +181,17 @@
    ``oe-selftest`` can run all tests by default or can run selected
    tests or test suites.
 
-   .. note::
-
-      Running ``oe-selftest`` requires host packages beyond the "Essential"
-      grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
-      section for more information.
-
 Originally, much of this testing was done manually. However, significant
 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::