blob: 172385ca4ee3178e8b84b3e1d95de3f83562d776 [file] [log] [blame]
Andrew Geissleraf5e4ef2020-10-16 10:22:50 -05001.. 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
15The Yocto Project delivers major releases (e.g. DISTRO) using a six
16month cadence roughly timed each April and October of the year.
17Following are examples of some major YP releases with their codenames
18also shown. See the "`Major Release
19Codenames <#major-release-codenames>`__" section for information on
20codenames used with major releases.
21
22 - 2.2 (Morty)
23 - 2.1 (Krogoth)
24 - 2.0 (Jethro)
25
26While the cadence is never perfect, this timescale facilitates
27regular releases that have strong QA cycles while not overwhelming users
28with too many new releases. The cadence is predictable and avoids many
29major holidays in various geographies.
30
31The Yocto project delivers minor (point) releases on an unscheduled
32basis and are usually driven by the accumulation of enough significant
33fixes or enhancements to the associated major release. Following are
34some example past point releases:
35
36 - 2.1.1
37 - 2.1.2
38 - 2.2.1
39
40The point release
41indicates a point in the major release branch where a full QA cycle and
42release process validates the content of the new branch.
43
44.. note::
45
46 Realize that there can be patches merged onto the stable release
47 branches as and when they become available.
48
49Major Release Codenames
50=======================
51
52Each major release receives a codename that identifies the release in
53the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
54The concept is that branches of :term:`Metadata` with the same
55codename are likely to be compatible and thus work together.
56
57.. note::
58
59 Codenames are associated with major releases because a Yocto Project
60 release number (e.g. DISTRO) could conflict with a given layer or
61 company versioning scheme. Codenames are unique, interesting, and
62 easily identifiable.
63
64Releases are given a nominal release version as well but the codename is
65used in repositories for this reason. You can find information on Yocto
66Project releases and codenames at
67https://wiki.yoctoproject.org/wiki/Releases.
68
69Stable Release Process
70======================
71
72Once released, the release enters the stable release process at which
73time a person is assigned as the maintainer for that stable release.
74This maintainer monitors activity for the release by investigating and
75handling nominated patches and backport activity. Only fixes and
76enhancements that have first been applied on the "master" branch (i.e.
77the current, in-development branch) are considered for backporting to a
78stable release.
79
80.. note::
81
82 The current Yocto Project policy regarding backporting is to consider
83 bug fixes and security fixes only. Policy dictates that features are
84 not backported to a stable release. This policy means generic recipe
85 version upgrades are unlikely to be accepted for backporting. The
86 exception to this policy occurs when a strong reason exists such as
87 the fix happens to also be the preferred upstream approach.
88
89Stable release branches have strong maintenance for about a year after
90their initial release. Should significant issues be found for any
91release regardless of its age, fixes could be backported to older
92releases. For issues that are not backported given an older release,
93Community LTS trees and branches exist where community members share
94patches for older releases. However, these types of patches do not go
95through the same release process as do point releases. You can find more
96information about stable branch maintenance at
97https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance.
98
99Testing and Quality Assurance
100=============================
101
102Part of the Yocto Project development and release process is quality
103assurance through the execution of test strategies. Test strategies
104provide the Yocto Project team a way to ensure a release is validated.
105Additionally, because the test strategies are visible to you as a
106developer, you can validate your projects. This section overviews the
107available test infrastructure used in the Yocto Project. For information
108on how to run available tests on your projects, see the
109":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
110section in the Yocto Project Development Tasks Manual.
111
112The QA/testing infrastructure is woven into the project to the point
113where core developers take some of it for granted. The infrastructure
114consists of the following pieces:
115
116- ``bitbake-selftest``: A standalone command that runs unit tests on
117 key pieces of BitBake and its fetchers.
118
119- :ref:`sanity.bbclass <ref-classes-sanity>`: This automatically
120 included class checks the build environment for missing tools (e.g.
121 ``gcc``) or common misconfigurations such as
122 :term:`MACHINE` set incorrectly.
123
124- :ref:`insane.bbclass <ref-classes-insane>`: This class checks the
125 generated output from builds for sanity. For example, if building for
126 an ARM target, did the build produce ARM binaries. If, for example,
127 the build produced PPC binaries then there is a problem.
128
129- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
130 performs runtime testing of images after they are built. The tests
131 are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>`
132 to boot the images and check the combined runtime result boot
133 operation and functions. However, the test can also use the IP
134 address of a machine to test.
135
136- :ref:`ptest <dev-manual/dev-manual-common-tasks:testing packages with ptest>`:
137 Runs tests against packages produced during the build for a given
138 piece of software. The test allows the packages to be be run within a
139 target image.
140
141- ``oe-selftest``: Tests combination BitBake invocations. These tests
142 operate outside the OpenEmbedded build system itself. The
143 ``oe-selftest`` can run all tests by default or can run selected
144 tests or test suites.
145
146 .. note::
147
148 Running
149 oe-selftest
150 requires host packages beyond the "Essential" grouping. See the "
151 Required Packages for the Build Host
152 " section for more information.
153
154Originally, much of this testing was done manually. However, significant
155effort has been made to automate the tests so that more people can use
156them and the Yocto Project development team can run them faster and more
157efficiently.
158
159The Yocto Project's main Autobuilder (https://autobuilder.yoctoproject.org/)
160publicly tests each Yocto Project release's code in the
161:term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
162occurs for both the current state of the "master" branch and also for
163submitted patches. Testing for submitted patches usually occurs in the
164"ross/mut" branch in the ``poky-contrib`` repository (i.e. the
165master-under-test branch) or in the "master-next" branch in the ``poky``
166repository.
167
168.. note::
169
170 You can find all these branches in the Yocto Project
171 Source Repositories
172 .
173
174Testing within these public branches ensures in a publicly visible way
175that all of the main supposed architectures and recipes in OE-Core
176successfully build and behave properly.
177
178Various features such as ``multilib``, sub architectures (e.g. ``x32``,
179``poky-tiny``, ``musl``, ``no-x11`` and and so forth),
180``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA
181process of a release. Complete testing and validation for a release
182takes the Autobuilder workers several hours.
183
184.. note::
185
186 The Autobuilder workers are non-homogeneous, which means regular
187 testing across a variety of Linux distributions occurs. The
188 Autobuilder is limited to only testing QEMU-based setups and not real
189 hardware.
190
191Finally, in addition to the Autobuilder's tests, the Yocto Project QA
192team also performs testing on a variety of platforms, which includes
193actual hardware, to ensure expected results.