diff options
Diffstat (limited to 'poky/documentation/ref-manual/release-process.rst')
| -rw-r--r-- | poky/documentation/ref-manual/release-process.rst | 72 |
1 files changed, 41 insertions, 31 deletions
diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst index fa057e055c..170565f9bc 100644 --- a/poky/documentation/ref-manual/release-process.rst +++ b/poky/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,22 +87,41 @@ 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`. +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 + add a specific feature or support a new version of some package for an :term:`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 + 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. @@ -113,7 +132,6 @@ information about stable branch maintenance at testing on them. Other "mixin" layers may be released elsewhere by the wider community. - Testing and Quality Assurance ============================= @@ -161,25 +179,17 @@ consists of the following pieces: ``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:: |