blob: 87f5308067d4b68873d4c532edf79f0d88a8e883 [file] [log] [blame]
Brad Bishop6e60e8b2018-02-01 10:27:11 -05001<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
Andrew Geissler475cb722020-07-10 16:00:51 -05004<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
Brad Bishop6e60e8b2018-02-01 10:27:11 -05005
6<chapter id='ref-release-process'>
7<title>Yocto Project Releases and the Stable Release Process</title>
8
9<para>
10 The Yocto Project release process is predictable and consists of both
11 major and minor (point) releases.
12 This brief chapter provides information on how releases are named, their
13 life cycle, and their stability.
14</para>
15
16<section id='major-and-minor-release-cadence'>
17 <title>Major and Minor Release Cadence</title>
18
19 <para>
20 The Yocto Project delivers major releases (e.g. &DISTRO;) using a six
21 month cadence roughly timed each April and October of the year.
22 Following are examples of some major YP releases with their codenames
23 also shown.
24 See the
25 "<link linkend='major-release-codenames'>Major Release Codenames</link>"
26 section for information on codenames used with major releases.
27 <literallayout class='monospaced'>
28 2.2 (Morty)
29 2.1 (Krogoth)
30 2.0 (Jethro)
31 </literallayout>
32 While the cadence is never perfect, this timescale facilitates
33 regular releases that have strong QA cycles while not overwhelming
34 users with too many new releases.
35 The cadence is predictable and avoids many major holidays in various
36 geographies.
37 </para>
38
39 <para>
40 The Yocto project delivers minor (point) releases on an unscheduled
41 basis and are usually driven by the accumulation of enough significant
42 fixes or enhancements to the associated major release.
43 Following are some example past point releases:
44 <literallayout class='monospaced'>
45 2.1.1
46 2.1.2
47 2.2.1
48 </literallayout>
49 The point release indicates a point in the major release branch where
50 a full QA cycle and release process validates the content of the new
51 branch.
52 <note>
53 Realize that there can be patches merged onto the stable release
54 branches as and when they become available.
55 </note>
56 </para>
57</section>
58
59<section id='major-release-codenames'>
60 <title>Major Release Codenames</title>
61
62 <para>
63 Each major release receives a codename that identifies the release in
64 the
Brad Bishop316dfdd2018-06-25 12:45:53 -040065 <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
Brad Bishop6e60e8b2018-02-01 10:27:11 -050066 The concept is that branches of
Brad Bishopd7bf8c12018-02-25 22:55:05 -050067 <link linkend='metadata'>Metadata</link>
Brad Bishop6e60e8b2018-02-01 10:27:11 -050068 with the same codename are likely to be compatible and thus
69 work together.
70 <note>
71 Codenames are associated with major releases because a Yocto
72 Project release number (e.g. &DISTRO;) could conflict with
73 a given layer or company versioning scheme.
74 Codenames are unique, interesting, and easily identifiable.
75 </note>
76 Releases are given a nominal release version as well but the codename
77 is used in repositories for this reason.
78 You can find information on Yocto Project releases and codenames at
79 <ulink url='https://wiki.yoctoproject.org/wiki/Releases'></ulink>.
80 </para>
81</section>
82
83<section id='stable-release-process'>
84 <title>Stable Release Process</title>
85
86 <para>
87 Once released, the release enters the stable release process at which
88 time a person is assigned as the maintainer for that stable release.
89 This maintainer monitors activity for the release by investigating
90 and handling nominated patches and backport activity.
91 Only fixes and enhancements that have first been applied on the
92 "master" branch (i.e. the current, in-development branch) are
93 considered for backporting to a stable release.
94 <note>
95 The current Yocto Project policy regarding backporting is to
96 consider bug fixes and security fixes only.
97 Policy dictates that features are not backported to a stable
98 release.
99 This policy means generic recipe version upgrades are unlikely to
100 be accepted for backporting.
101 The exception to this policy occurs when a strong reason exists
102 such as the fix happens to also be the preferred upstream approach.
103 </note>
104 </para>
105
106 <para>
107 Stable release branches have strong maintenance for about a year after
108 their initial release.
109 Should significant issues be found for any release regardless of its
110 age, fixes could be backported to older releases.
111 For issues that are not backported given an older release,
112 Community LTS trees and branches exist where
113 community members share patches for older releases.
114 However, these types of patches do not go through the same release
115 process as do point releases.
116 You can find more information about stable branch maintenance at
117 <ulink url='https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance'></ulink>.
118 </para>
119</section>
120
121<section id='testing-and-quality-assurance'>
122 <title>Testing and Quality Assurance</title>
123
124 <para>
125 Part of the Yocto Project development and release process is quality
126 assurance through the execution of test strategies.
127 Test strategies provide the Yocto Project team a way to ensure a
128 release is validated.
129 Additionally, because the test strategies are visible to you as a
130 developer, you can validate your projects.
131 This section overviews the available test infrastructure used in the
132 Yocto Project.
133 For information on how to run available tests on your projects, see the
134 "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
Brad Bishopd7bf8c12018-02-25 22:55:05 -0500135 section in the Yocto Project Development Tasks Manual.
Brad Bishop6e60e8b2018-02-01 10:27:11 -0500136 </para>
137
138 <para>
139 The QA/testing infrastructure is woven into the project to the point
140 where core developers take some of it for granted.
141 The infrastructure consists of the following pieces:
142 <itemizedlist>
143 <listitem><para>
144 <filename>bitbake-selftest</filename>:
145 A standalone command that runs unit tests on key pieces of
146 BitBake and its fetchers.
147 </para></listitem>
148 <listitem><para>
149 <link linkend='ref-classes-sanity'><filename>sanity.bbclass</filename></link>:
150 This automatically included class checks the build environment
151 for missing tools (e.g. <filename>gcc</filename>) or common
152 misconfigurations such as
153 <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
154 set incorrectly.
155 </para></listitem>
156 <listitem><para>
157 <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>:
158 This class checks the generated output from builds for sanity.
159 For example, if building for an ARM target, did the build
160 produce ARM binaries.
161 If, for example, the build produced PPC binaries then there
162 is a problem.
163 </para></listitem>
164 <listitem><para>
165 <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>:
166 This class performs runtime testing of images after they are
167 built.
168 The tests are usually used with
169 <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU</ulink>
170 to boot the images and check the combined runtime result
171 boot operation and functions.
172 However, the test can also use the IP address of a machine to
173 test.
174 </para></listitem>
175 <listitem><para>
176 <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'><filename>ptest</filename></ulink>:
177 Runs tests against packages produced during the build for a
178 given piece of software.
179 The test allows the packages to be be run within a target
180 image.
181 </para></listitem>
182 <listitem><para>
183 <filename>oe-selftest</filename>:
184 Tests combination BitBake invocations.
185 These tests operate outside the OpenEmbedded build system
186 itself.
187 The <filename>oe-selftest</filename> can run all tests by
188 default or can run selected tests or test suites.
189 <note>
190 Running <filename>oe-selftest</filename> requires
191 host packages beyond the "Essential" grouping.
192 See the
Brad Bishop1a4b7ee2018-12-16 17:11:34 -0800193 "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>"
Brad Bishop6e60e8b2018-02-01 10:27:11 -0500194 section for more information.
195 </note>
196 </para></listitem>
197 </itemizedlist>
198 </para>
199
200 <para>
201 Originally, much of this testing was done manually.
202 However, significant effort has been made to automate the tests so
203 that more people can use them and the Yocto Project development team
204 can run them faster and more efficiently.
205 </para>
206
207 <para>
208 The Yocto Project's main Autobuilder
209 (<filename>autobuilder.yoctoproject.org</filename>) publicly tests
Brad Bishopd7bf8c12018-02-25 22:55:05 -0500210 each Yocto Project release's code in the
211 <link linkend='oe-core'>OE-Core</link>, Poky, and BitBake
Brad Bishop6e60e8b2018-02-01 10:27:11 -0500212 repositories.
213 The testing occurs for both the current state of the
214 "master" branch and also for submitted patches.
215 Testing for submitted patches usually occurs in the
216 "ross/mut" branch in the <filename>poky-contrib</filename> repository
217 (i.e. the master-under-test branch) or in the "master-next" branch
218 in the <filename>poky</filename> repository.
219 <note>
220 You can find all these branches in the Yocto Project
Brad Bishop316dfdd2018-06-25 12:45:53 -0400221 <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>.
Brad Bishop6e60e8b2018-02-01 10:27:11 -0500222 </note>
223 Testing within these public branches ensures in a publicly visible way
224 that all of the main supposed architectures and recipes in OE-Core
225 successfully build and behave properly.
226 </para>
227
228 <para>
229 Various features such as <filename>multilib</filename>, sub
230 architectures (e.g. <filename>x32</filename>,
231 <filename>poky-tiny</filename>, <filename>musl</filename>,
232 <filename>no-x11</filename> and and so forth),
233 <filename>bitbake-selftest</filename>, and
234 <filename>oe-selftest</filename> are tested as part of
235 the QA process of a release.
236 Complete testing and validation for a release takes the Autobuilder
237 workers several hours.
238 <note>
239 The Autobuilder workers are non-homogeneous, which means regular
240 testing across a variety of Linux distributions occurs.
241 The Autobuilder is limited to only testing QEMU-based setups and
242 not real hardware.
243 </note>
244 </para>
245
246 <para>
247 Finally, in addition to the Autobuilder's tests, the Yocto Project
248 QA team also performs testing on a variety of platforms, which includes
249 actual hardware, to ensure expected results.
250 </para>
251</section>
252
253</chapter>
254<!--
255vim: expandtab tw=80 ts=4
256-->