blob: c861feaa9dee055716bb94093e1e9402dbf1debc [file] [log] [blame]
Andrew Geisslerf0343792020-11-18 10:42:21 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
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
Andrew Geisslerd1e89492021-02-12 15:35:20 -060015The Yocto Project delivers major releases (e.g. &DISTRO;) using a six
Andrew Geisslerc9f78652020-09-18 14:11:35 -050016month cadence roughly timed each April and October of the year.
17Following are examples of some major YP releases with their codenames
Andrew Geissler3b8a17c2021-04-15 15:55:55 -050018also shown. See the ":ref:`ref-manual/release-process:major release codenames`"
19section for information on codenames used with major releases.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050020
Patrick Williams8e7b46e2023-05-01 14:19:06 -050021 - 4.1 ("Langdale")
22 - 4.0 ("Kirkstone")
23 - 3.4 ("Honister")
Andrew Geisslerc9f78652020-09-18 14:11:35 -050024
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. Following are
33some example past point releases:
34
Patrick Williams8e7b46e2023-05-01 14:19:06 -050035 - 4.1.3
36 - 4.0.8
37 - 3.4.4
Andrew Geisslerc9f78652020-09-18 14:11:35 -050038
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
Andrew Geissler09209ee2020-12-13 08:44:15 -060052the :ref:`overview-manual/development-environment:yocto project source repositories`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050053The 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
Andrew Geisslerd1e89492021-02-12 15:35:20 -060059 release number (e.g. &DISTRO;) could conflict with a given layer or
Andrew Geisslerc9f78652020-09-18 14:11:35 -050060 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
Andrew Geissler09036742021-06-25 14:25:14 -050065Project 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.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050069
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
William A. Kennington IIIac69b482021-06-02 12:28:27 -070087 exception to this policy occurs when there is a strong reason such as
Andrew Geisslerc9f78652020-09-18 14:11:35 -050088 the fix happens to also be the preferred upstream approach.
89
Patrick Williams8e7b46e2023-05-01 14:19:06 -050090.. _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
Patrick Williams8e7b46e2023-05-01 14:19:06 -050099When 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
Patrick Williams2a254922023-08-11 09:48:11 -0500104This 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
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500114See :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%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500119
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500120.. note::
121
122 In some circumstances, a layer can be created by the community in order to
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500123 add a specific feature or support a new version of some package for an :term:`LTS`
Patrick Williams520786c2023-06-25 16:20:36 -0500124 release. This is called a :term:`Mixin` layer. These are thin and specific
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500125 purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500126 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
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500130 determined on a case-by-case basis. You can find some :term:`Mixin` layers in the
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500131 :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto
132 Project provides hosting for those repositories, it does not provides
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500133 testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500134 community.
135
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500136Testing 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
Andrew Geissler517393d2023-01-13 08:55:19 -0600146":ref:`dev-manual/runtime-testing:performing automated runtime testing`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500147section 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
Andrew Geissler7e0e3c02022-02-25 20:34:39 +0000156- :ref:`ref-classes-sanity`: This automatically
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500157 included class checks the build environment for missing tools (e.g.
158 ``gcc``) or common misconfigurations such as
159 :term:`MACHINE` set incorrectly.
160
Andrew Geissler7e0e3c02022-02-25 20:34:39 +0000161- :ref:`ref-classes-insane`: This class checks the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500162 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
Patrick Williams975a06f2022-10-21 14:42:47 -0500166- :ref:`ref-classes-testimage`: This class
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500167 performs runtime testing of images after they are built. The tests
Andrew Geissler09209ee2020-12-13 08:44:15 -0600168 are usually used with :doc:`QEMU </dev-manual/qemu>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500169 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
Andrew Geissler517393d2023-01-13 08:55:19 -0600173- :ref:`ptest <dev-manual/packages:testing packages with ptest>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500174 Runs tests against packages produced during the build for a given
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500175 piece of software. The test allows the packages to be run within a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500176 target image.
177
178- ``oe-selftest``: Tests combination 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
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500183Originally, 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
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500188The 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
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500192submitted patches. Testing for submitted patches usually occurs in the
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500193in the "master-next" branch in the :yocto_git:`poky </poky>` repository.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500194
195.. note::
196
Andrew Geissler09036742021-06-25 14:25:14 -0500197 You can find all these branches in the
198 :ref:`overview-manual/development-environment:yocto project source repositories`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500199
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.