1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3***************************************************** 4Yocto Project Releases and the Stable Release Process 5***************************************************** 6 7The Yocto Project release process is predictable and consists of both 8major and minor (point) releases. This brief chapter provides 9information on how releases are named, their life cycle, and their 10stability. 11 12Major and Minor Release Cadence 13=============================== 14 15The Yocto Project delivers major releases (e.g. &DISTRO;) using a six 16month cadence roughly timed each April and October of the year. 17Here are examples of some major YP releases with their codenames 18also shown. See the ":ref:`ref-manual/release-process:major release codenames`" 19section for information on codenames used with major releases. 20 21 - 4.1 ("Langdale") 22 - 4.0 ("Kirkstone") 23 - 3.4 ("Honister") 24 25While the cadence is never perfect, this timescale facilitates 26regular releases that have strong QA cycles while not overwhelming users 27with too many new releases. The cadence is predictable and avoids many 28major holidays in various geographies. 29 30The Yocto project delivers minor (point) releases on an unscheduled 31basis and are usually driven by the accumulation of enough significant 32fixes or enhancements to the associated major release. 33Some example past point releases are: 34 35 - 4.1.3 36 - 4.0.8 37 - 3.4.4 38 39The point release 40indicates a point in the major release branch where a full QA cycle and 41release process validates the content of the new branch. 42 43.. note:: 44 45 Realize that there can be patches merged onto the stable release 46 branches as and when they become available. 47 48Major Release Codenames 49======================= 50 51Each major release receives a codename that identifies the release in 52the :ref:`overview-manual/development-environment:yocto project source repositories`. 53The concept is that branches of :term:`Metadata` with the same 54codename are likely to be compatible and thus work together. 55 56.. note:: 57 58 Codenames are associated with major releases because a Yocto Project 59 release number (e.g. &DISTRO;) could conflict with a given layer or 60 company versioning scheme. Codenames are unique, interesting, and 61 easily identifiable. 62 63Releases are given a nominal release version as well but the codename is 64used in repositories for this reason. You can find information on Yocto 65Project releases and codenames at :yocto_wiki:`/Releases`. 66 67Our :doc:`/migration-guides/index` detail how to migrate from one release of 68the Yocto Project to the next. 69 70Stable Release Process 71====================== 72 73Once released, the release enters the stable release process at which 74time a person is assigned as the maintainer for that stable release. 75This maintainer monitors activity for the release by investigating and 76handling nominated patches and backport activity. Only fixes and 77enhancements that have first been applied on the "master" branch (i.e. 78the current, in-development branch) are considered for backporting to a 79stable release. 80 81.. note:: 82 83 The current Yocto Project policy regarding backporting is to consider 84 bug fixes and security fixes only. Policy dictates that features are 85 not backported to a stable release. This policy means generic recipe 86 version upgrades are unlikely to be accepted for backporting. The 87 exception to this policy occurs when there is a strong reason such as 88 the fix happens to also be the preferred upstream approach. 89 90.. _ref-long-term-support-releases: 91 92Long Term Support Releases 93========================== 94 95While stable releases are supported for a duration of seven months, 96some specific ones are now supported for a longer period by the Yocto 97Project, and are called Long Term Support (:term:`LTS`) releases. 98 99When significant issues are found, :term:`LTS` releases allow to publish 100fixes not only for the current stable release, but also to the 101:term:`LTS` releases that are still supported. Older stable releases which 102have reached their End of Life (EOL) won't receive such updates. 103 104This started with version 3.1 ("Dunfell"), released in April 2020, which 105the project initially committed to supporting for two years, but this duration 106was later extended to four years. 107 108A new :term:`LTS` release is made every two years and is supported for four 109years. This offers more stability to project users and leaves more time to 110upgrade to the following :term:`LTS` release. 111 112The currently supported :term:`LTS` releases are: 113 114- Version 5.0 ("Scarthgap"), released in April 2024 and supported until April 2028. 115- Version 4.0 ("Kirkstone"), released in May 2022 and supported until May 2026. 116 117See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management 118of stable and :term:`LTS` releases. 119 120This documentation was built for the &DISTRO_NAME; release. 121 122.. image:: svg/releases.* 123 :width: 100% 124 125.. note:: 126 127 In some circumstances, a layer can be created by the community in order to 128 add a specific feature or support a new version of some package for an :term:`LTS` 129 release. This is called a :term:`Mixin` layer. These are thin and specific 130 purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific 131 feature into that build. These are created on an as-needed basis and 132 maintained by the people who need them. 133 134 Policies on testing these layers depend on how widespread their usage is and 135 determined on a case-by-case basis. You can find some :term:`Mixin` layers in the 136 :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto 137 Project provides hosting for those repositories, it does not provides 138 testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider 139 community. 140 141Testing and Quality Assurance 142============================= 143 144Part of the Yocto Project development and release process is quality 145assurance through the execution of test strategies. Test strategies 146provide the Yocto Project team a way to ensure a release is validated. 147Additionally, because the test strategies are visible to you as a 148developer, you can validate your projects. This section overviews the 149available test infrastructure used in the Yocto Project. For information 150on how to run available tests on your projects, see the 151":ref:`test-manual/runtime-testing:performing automated runtime testing`" 152section in the Yocto Project Test Environment Manual. 153 154The QA/testing infrastructure is woven into the project to the point 155where core developers take some of it for granted. The infrastructure 156consists of the following pieces: 157 158- ``bitbake-selftest``: A standalone command that runs unit tests on 159 key pieces of BitBake and its fetchers. 160 161- :ref:`ref-classes-sanity`: This automatically 162 included class checks the build environment for missing tools (e.g. 163 ``gcc``) or common misconfigurations such as 164 :term:`MACHINE` set incorrectly. 165 166- :ref:`ref-classes-insane`: This class checks the 167 generated output from builds for sanity. For example, if building for 168 an ARM target, did the build produce ARM binaries. If, for example, 169 the build produced PPC binaries then there is a problem. 170 171- :ref:`ref-classes-testimage`: This class 172 performs runtime testing of images after they are built. The tests 173 are usually used with :doc:`QEMU </dev-manual/qemu>` 174 to boot the images and check the combined runtime result boot 175 operation and functions. However, the test can also use the IP 176 address of a machine to test. 177 178- :ref:`ptest <test-manual/ptest:testing packages with ptest>`: 179 Runs tests against packages produced during the build for a given 180 piece of software. The test allows the packages to be run within a 181 target image. 182 183- ``oe-selftest``: Tests combinations of BitBake invocations. These tests 184 operate outside the OpenEmbedded build system itself. The 185 ``oe-selftest`` can run all tests by default or can run selected 186 tests or test suites. 187 188Originally, much of this testing was done manually. However, significant 189effort has been made to automate the tests so that more people can use 190them and the Yocto Project development team can run them faster and more 191efficiently. 192 193The Yocto Project's main :yocto_ab:`Autobuilder <>` publicly tests each Yocto 194Project release's code in the :oe_git:`openembedded-core </openembedded-core>`, 195:yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The 196testing occurs for both the current state of the "master" branch and also for 197submitted patches. Testing for submitted patches usually occurs in the 198in the "master-next" branch in the :yocto_git:`poky </poky>` repository. 199 200.. note:: 201 202 You can find all these branches in the 203 :ref:`overview-manual/development-environment:yocto project source repositories`. 204 205Testing within these public branches ensures in a publicly visible way 206that all of the main supposed architectures and recipes in OE-Core 207successfully build and behave properly. 208 209Various features such as ``multilib``, sub architectures (e.g. ``x32``, 210``poky-tiny``, ``musl``, ``no-x11`` and and so forth), 211``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA 212process of a release. Complete testing and validation for a release 213takes the Autobuilder workers several hours. 214 215.. note:: 216 217 The Autobuilder workers are non-homogeneous, which means regular 218 testing across a variety of Linux distributions occurs. The 219 Autobuilder is limited to only testing QEMU-based setups and not real 220 hardware. 221 222Finally, in addition to the Autobuilder's tests, the Yocto Project QA 223team also performs testing on a variety of platforms, which includes 224actual hardware, to ensure expected results. 225