blob: 2ffbd935c73b237358d888198f1562ffecfb6882 [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
99This started with version 3.1 ("Dunfell"), released in April 2020, that
100the project committed to supporting until the next :term:`LTS` release was out.
101This next :term:`LTS` release, version 4.0 ("Kirkstone"), was released in May 2022
102and offered with two years of support too.
103
104However, as an experiment, support for "Dunfell" was extended to four years, until
105April 2024, therefore offering more stability to projects and leaving more time
106to upgrade to the latest :term:`LTS` release. The project hasn't made any commitment to
107extending "Kirkstone" support too, as this will also depend on available funding
108for such an effort.
109
110When significant issues are found, :term:`LTS` releases allow to publish
111fixes not only for the current stable release, but also to the
112:term:`LTS` releases that are still supported. Older stable releases which
113have reached their End of Life (EOL) won't receive such updates.
114
115See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management
116of stable and :term:`LTS` releases.
117
118.. image:: svg/releases.*
119 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500120
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500121.. note::
122
123 In some circumstances, a layer can be created by the community in order to
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500124 add a specific feature or support a new version of some package for an :term:`LTS`
125 release. This is called a :term:`Mixin` layer. These are thin and specific
126 purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500127 feature into that build. These are created on an as-needed basis and
128 maintained by the people who need them.
129
130 Policies on testing these layers depend on how widespread their usage is and
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500131 determined on a case-by-case basis. You can find some :term:`Mixin` layers in the
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500132 :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto
133 Project provides hosting for those repositories, it does not provides
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500134 testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider
Andrew Geisslerfc113ea2023-03-31 09:59:46 -0500135 community.
136
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500137Testing and Quality Assurance
138=============================
139
140Part of the Yocto Project development and release process is quality
141assurance through the execution of test strategies. Test strategies
142provide the Yocto Project team a way to ensure a release is validated.
143Additionally, because the test strategies are visible to you as a
144developer, you can validate your projects. This section overviews the
145available test infrastructure used in the Yocto Project. For information
146on how to run available tests on your projects, see the
Andrew Geissler517393d2023-01-13 08:55:19 -0600147":ref:`dev-manual/runtime-testing:performing automated runtime testing`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500148section in the Yocto Project Development Tasks Manual.
149
150The QA/testing infrastructure is woven into the project to the point
151where core developers take some of it for granted. The infrastructure
152consists of the following pieces:
153
154- ``bitbake-selftest``: A standalone command that runs unit tests on
155 key pieces of BitBake and its fetchers.
156
Andrew Geissler7e0e3c02022-02-25 20:34:39 +0000157- :ref:`ref-classes-sanity`: This automatically
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500158 included class checks the build environment for missing tools (e.g.
159 ``gcc``) or common misconfigurations such as
160 :term:`MACHINE` set incorrectly.
161
Andrew Geissler7e0e3c02022-02-25 20:34:39 +0000162- :ref:`ref-classes-insane`: This class checks the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500163 generated output from builds for sanity. For example, if building for
164 an ARM target, did the build produce ARM binaries. If, for example,
165 the build produced PPC binaries then there is a problem.
166
Patrick Williams975a06f2022-10-21 14:42:47 -0500167- :ref:`ref-classes-testimage`: This class
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500168 performs runtime testing of images after they are built. The tests
Andrew Geissler09209ee2020-12-13 08:44:15 -0600169 are usually used with :doc:`QEMU </dev-manual/qemu>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500170 to boot the images and check the combined runtime result boot
171 operation and functions. However, the test can also use the IP
172 address of a machine to test.
173
Andrew Geissler517393d2023-01-13 08:55:19 -0600174- :ref:`ptest <dev-manual/packages:testing packages with ptest>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500175 Runs tests against packages produced during the build for a given
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500176 piece of software. The test allows the packages to be run within a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500177 target image.
178
179- ``oe-selftest``: Tests combination BitBake invocations. These tests
180 operate outside the OpenEmbedded build system itself. The
181 ``oe-selftest`` can run all tests by default or can run selected
182 tests or test suites.
183
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500184Originally, much of this testing was done manually. However, significant
185effort has been made to automate the tests so that more people can use
186them and the Yocto Project development team can run them faster and more
187efficiently.
188
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500189The Yocto Project's main Autobuilder (&YOCTO_AB_URL;) publicly tests each Yocto
190Project release's code in the :oe_git:`openembedded-core </openembedded-core>`,
191:yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The
192testing occurs for both the current state of the "master" branch and also for
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500193submitted patches. Testing for submitted patches usually occurs in the
Patrick Williams8e7b46e2023-05-01 14:19:06 -0500194in the "master-next" branch in the :yocto_git:`poky </poky>` repository.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500195
196.. note::
197
Andrew Geissler09036742021-06-25 14:25:14 -0500198 You can find all these branches in the
199 :ref:`overview-manual/development-environment:yocto project source repositories`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500200
201Testing within these public branches ensures in a publicly visible way
202that all of the main supposed architectures and recipes in OE-Core
203successfully build and behave properly.
204
205Various features such as ``multilib``, sub architectures (e.g. ``x32``,
206``poky-tiny``, ``musl``, ``no-x11`` and and so forth),
207``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA
208process of a release. Complete testing and validation for a release
209takes the Autobuilder workers several hours.
210
211.. note::
212
213 The Autobuilder workers are non-homogeneous, which means regular
214 testing across a variety of Linux distributions occurs. The
215 Autobuilder is limited to only testing QEMU-based setups and not real
216 hardware.
217
218Finally, in addition to the Autobuilder's tests, the Yocto Project QA
219team also performs testing on a variety of platforms, which includes
220actual hardware, to ensure expected results.