diff options
Diffstat (limited to 'documentation/ref-manual/ref-release-process.xml')
-rw-r--r-- | documentation/ref-manual/ref-release-process.xml | 256 |
1 files changed, 0 insertions, 256 deletions
diff --git a/documentation/ref-manual/ref-release-process.xml b/documentation/ref-manual/ref-release-process.xml deleted file mode 100644 index 87f5308067..0000000000 --- a/documentation/ref-manual/ref-release-process.xml +++ /dev/null | |||
@@ -1,256 +0,0 @@ | |||
1 | <!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; ] > | ||
4 | <!--SPDX-License-Identifier: CC-BY-2.0-UK--> | ||
5 | |||
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 | ||
65 | <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>. | ||
66 | The concept is that branches of | ||
67 | <link linkend='metadata'>Metadata</link> | ||
68 | 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>" | ||
135 | section in the Yocto Project Development Tasks Manual. | ||
136 | </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 | ||
193 | "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>" | ||
194 | 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 | ||
210 | each Yocto Project release's code in the | ||
211 | <link linkend='oe-core'>OE-Core</link>, Poky, and BitBake | ||
212 | 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 | ||
221 | <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>. | ||
222 | </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 | <!-- | ||
255 | vim: expandtab tw=80 ts=4 | ||
256 | --> | ||