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. Similarly, the following :term:`LTS` release,
107version 4.0 ("Kirkstone"), was released two years later in May 2022 and the
108project committed to supporting it for four years too.
109
110Therefore, a new :term:`LTS` release is made every two years and is supported
111for four years. This offers more stability to project users and leaves more
112time to upgrade to the following :term:`LTS` release.
113
114See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management
115of stable and :term:`LTS` releases.
116
117.. image:: svg/releases.*
118   :width: 100%
119
120.. note::
121
122   In some circumstances, a layer can be created by the community in order to
123   add a specific feature or support a new version of some package for an :term:`LTS`
124   release. This is called a :term:`Mixin` layer. These are thin and specific
125   purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific
126   feature into that build. These are created on an as-needed basis and
127   maintained by the people who need them.
128
129   Policies on testing these layers depend on how widespread their usage is and
130   determined on a case-by-case basis. You can find some :term:`Mixin` layers in the
131   :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto
132   Project provides hosting for those repositories, it does not provides
133   testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider
134   community.
135
136Testing and Quality Assurance
137=============================
138
139Part of the Yocto Project development and release process is quality
140assurance through the execution of test strategies. Test strategies
141provide the Yocto Project team a way to ensure a release is validated.
142Additionally, because the test strategies are visible to you as a
143developer, you can validate your projects. This section overviews the
144available test infrastructure used in the Yocto Project. For information
145on how to run available tests on your projects, see the
146":ref:`dev-manual/runtime-testing:performing automated runtime testing`"
147section in the Yocto Project Development Tasks Manual.
148
149The QA/testing infrastructure is woven into the project to the point
150where core developers take some of it for granted. The infrastructure
151consists of the following pieces:
152
153-  ``bitbake-selftest``: A standalone command that runs unit tests on
154   key pieces of BitBake and its fetchers.
155
156-  :ref:`ref-classes-sanity`: This automatically
157   included class checks the build environment for missing tools (e.g.
158   ``gcc``) or common misconfigurations such as
159   :term:`MACHINE` set incorrectly.
160
161-  :ref:`ref-classes-insane`: This class checks the
162   generated output from builds for sanity. For example, if building for
163   an ARM target, did the build produce ARM binaries. If, for example,
164   the build produced PPC binaries then there is a problem.
165
166-  :ref:`ref-classes-testimage`: This class
167   performs runtime testing of images after they are built. The tests
168   are usually used with :doc:`QEMU </dev-manual/qemu>`
169   to boot the images and check the combined runtime result boot
170   operation and functions. However, the test can also use the IP
171   address of a machine to test.
172
173-  :ref:`ptest <dev-manual/packages:testing packages with ptest>`:
174   Runs tests against packages produced during the build for a given
175   piece of software. The test allows the packages to be run within a
176   target image.
177
178-  ``oe-selftest``: Tests combinations of BitBake invocations. These tests
179   operate outside the OpenEmbedded build system itself. The
180   ``oe-selftest`` can run all tests by default or can run selected
181   tests or test suites.
182
183Originally, much of this testing was done manually. However, significant
184effort has been made to automate the tests so that more people can use
185them and the Yocto Project development team can run them faster and more
186efficiently.
187
188The Yocto Project's main Autobuilder (&YOCTO_AB_URL;) publicly tests each Yocto
189Project release's code in the :oe_git:`openembedded-core </openembedded-core>`,
190:yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The
191testing occurs for both the current state of the "master" branch and also for
192submitted patches. Testing for submitted patches usually occurs in the
193in the "master-next" branch in the :yocto_git:`poky </poky>` repository.
194
195.. note::
196
197   You can find all these branches in the
198   :ref:`overview-manual/development-environment:yocto project source repositories`.
199
200Testing within these public branches ensures in a publicly visible way
201that all of the main supposed architectures and recipes in OE-Core
202successfully build and behave properly.
203
204Various features such as ``multilib``, sub architectures (e.g. ``x32``,
205``poky-tiny``, ``musl``, ``no-x11`` and and so forth),
206``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA
207process of a release. Complete testing and validation for a release
208takes the Autobuilder workers several hours.
209
210.. note::
211
212   The Autobuilder workers are non-homogeneous, which means regular
213   testing across a variety of Linux distributions occurs. The
214   Autobuilder is limited to only testing QEMU-based setups and not real
215   hardware.
216
217Finally, in addition to the Autobuilder's tests, the Yocto Project QA
218team also performs testing on a variety of platforms, which includes
219actual hardware, to ensure expected results.
220