blob: ab143f7df0ac8b576490adbf50d988b8d97f1c92 [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
21 - 2.2 (Morty)
22 - 2.1 (Krogoth)
23 - 2.0 (Jethro)
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. Following are
33some example past point releases:
34
35 - 2.1.1
36 - 2.1.2
37 - 2.2.1
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
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
90Stable release branches have strong maintenance for about a year after
91their initial release. Should significant issues be found for any
92release regardless of its age, fixes could be backported to older
93releases. For issues that are not backported given an older release,
William A. Kennington IIIac69b482021-06-02 12:28:27 -070094Community LTS trees and branches allow community members to share
Andrew Geisslerc9f78652020-09-18 14:11:35 -050095patches for older releases. However, these types of patches do not go
96through the same release process as do point releases. You can find more
97information about stable branch maintenance at
Andrew Geissler09209ee2020-12-13 08:44:15 -060098:yocto_wiki:`/Stable_branch_maintenance`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -050099
100Testing and Quality Assurance
101=============================
102
103Part of the Yocto Project development and release process is quality
104assurance through the execution of test strategies. Test strategies
105provide the Yocto Project team a way to ensure a release is validated.
106Additionally, because the test strategies are visible to you as a
107developer, you can validate your projects. This section overviews the
108available test infrastructure used in the Yocto Project. For information
109on how to run available tests on your projects, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600110":ref:`dev-manual/common-tasks:performing automated runtime testing`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500111section in the Yocto Project Development Tasks Manual.
112
113The QA/testing infrastructure is woven into the project to the point
114where core developers take some of it for granted. The infrastructure
115consists of the following pieces:
116
117- ``bitbake-selftest``: A standalone command that runs unit tests on
118 key pieces of BitBake and its fetchers.
119
120- :ref:`sanity.bbclass <ref-classes-sanity>`: This automatically
121 included class checks the build environment for missing tools (e.g.
122 ``gcc``) or common misconfigurations such as
123 :term:`MACHINE` set incorrectly.
124
125- :ref:`insane.bbclass <ref-classes-insane>`: This class checks the
126 generated output from builds for sanity. For example, if building for
127 an ARM target, did the build produce ARM binaries. If, for example,
128 the build produced PPC binaries then there is a problem.
129
130- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
131 performs runtime testing of images after they are built. The tests
Andrew Geissler09209ee2020-12-13 08:44:15 -0600132 are usually used with :doc:`QEMU </dev-manual/qemu>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500133 to boot the images and check the combined runtime result boot
134 operation and functions. However, the test can also use the IP
135 address of a machine to test.
136
Andrew Geissler09209ee2020-12-13 08:44:15 -0600137- :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500138 Runs tests against packages produced during the build for a given
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500139 piece of software. The test allows the packages to be run within a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500140 target image.
141
142- ``oe-selftest``: Tests combination BitBake invocations. These tests
143 operate outside the OpenEmbedded build system itself. The
144 ``oe-selftest`` can run all tests by default or can run selected
145 tests or test suites.
146
147 .. note::
148
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500149 Running ``oe-selftest`` requires host packages beyond the "Essential"
Andrew Geissler09209ee2020-12-13 08:44:15 -0600150 grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500151 section for more information.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500152
153Originally, much of this testing was done manually. However, significant
154effort has been made to automate the tests so that more people can use
155them and the Yocto Project development team can run them faster and more
156efficiently.
157
Andrew Geissler4c19ea12020-10-27 13:52:24 -0500158The Yocto Project's main Autobuilder (&YOCTO_AB_URL;)
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500159publicly tests each Yocto Project release's code in the
160:term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
161occurs for both the current state of the "master" branch and also for
162submitted patches. Testing for submitted patches usually occurs in the
163"ross/mut" branch in the ``poky-contrib`` repository (i.e. the
164master-under-test branch) or in the "master-next" branch in the ``poky``
165repository.
166
167.. note::
168
Andrew Geissler09036742021-06-25 14:25:14 -0500169 You can find all these branches in the
170 :ref:`overview-manual/development-environment:yocto project source repositories`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500171
172Testing within these public branches ensures in a publicly visible way
173that all of the main supposed architectures and recipes in OE-Core
174successfully build and behave properly.
175
176Various features such as ``multilib``, sub architectures (e.g. ``x32``,
177``poky-tiny``, ``musl``, ``no-x11`` and and so forth),
178``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA
179process of a release. Complete testing and validation for a release
180takes the Autobuilder workers several hours.
181
182.. note::
183
184 The Autobuilder workers are non-homogeneous, which means regular
185 testing across a variety of Linux distributions occurs. The
186 Autobuilder is limited to only testing QEMU-based setups and not real
187 hardware.
188
189Finally, in addition to the Autobuilder's tests, the Yocto Project QA
190team also performs testing on a variety of platforms, which includes
191actual hardware, to ensure expected results.