diff options
Diffstat (limited to 'documentation/ref-manual/ref-release-process.rst')
-rw-r--r-- | documentation/ref-manual/ref-release-process.rst | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst new file mode 100644 index 0000000000..be041e7254 --- /dev/null +++ b/documentation/ref-manual/ref-release-process.rst | |||
@@ -0,0 +1,193 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-2.0-UK | ||
2 | |||
3 | ***************************************************** | ||
4 | Yocto Project Releases and the Stable Release Process | ||
5 | ***************************************************** | ||
6 | |||
7 | The Yocto Project release process is predictable and consists of both | ||
8 | major and minor (point) releases. This brief chapter provides | ||
9 | information on how releases are named, their life cycle, and their | ||
10 | stability. | ||
11 | |||
12 | Major and Minor Release Cadence | ||
13 | =============================== | ||
14 | |||
15 | The Yocto Project delivers major releases (e.g. DISTRO) using a six | ||
16 | month cadence roughly timed each April and October of the year. | ||
17 | Following are examples of some major YP releases with their codenames | ||
18 | also shown. See the "`Major Release | ||
19 | Codenames <#major-release-codenames>`__" section for information on | ||
20 | codenames used with major releases. | ||
21 | |||
22 | - 2.2 (Morty) | ||
23 | - 2.1 (Krogoth) | ||
24 | - 2.0 (Jethro) | ||
25 | |||
26 | While the cadence is never perfect, this timescale facilitates | ||
27 | regular releases that have strong QA cycles while not overwhelming users | ||
28 | with too many new releases. The cadence is predictable and avoids many | ||
29 | major holidays in various geographies. | ||
30 | |||
31 | The Yocto project delivers minor (point) releases on an unscheduled | ||
32 | basis and are usually driven by the accumulation of enough significant | ||
33 | fixes or enhancements to the associated major release. Following are | ||
34 | some example past point releases: | ||
35 | |||
36 | - 2.1.1 | ||
37 | - 2.1.2 | ||
38 | - 2.2.1 | ||
39 | |||
40 | The point release | ||
41 | indicates a point in the major release branch where a full QA cycle and | ||
42 | release 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 | |||
49 | Major Release Codenames | ||
50 | ======================= | ||
51 | |||
52 | Each major release receives a codename that identifies the release in | ||
53 | the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`. | ||
54 | The concept is that branches of :term:`Metadata` with the same | ||
55 | codename 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 | |||
64 | Releases are given a nominal release version as well but the codename is | ||
65 | used in repositories for this reason. You can find information on Yocto | ||
66 | Project releases and codenames at | ||
67 | https://wiki.yoctoproject.org/wiki/Releases. | ||
68 | |||
69 | Stable Release Process | ||
70 | ====================== | ||
71 | |||
72 | Once released, the release enters the stable release process at which | ||
73 | time a person is assigned as the maintainer for that stable release. | ||
74 | This maintainer monitors activity for the release by investigating and | ||
75 | handling nominated patches and backport activity. Only fixes and | ||
76 | enhancements that have first been applied on the "master" branch (i.e. | ||
77 | the current, in-development branch) are considered for backporting to a | ||
78 | stable 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 | |||
89 | Stable release branches have strong maintenance for about a year after | ||
90 | their initial release. Should significant issues be found for any | ||
91 | release regardless of its age, fixes could be backported to older | ||
92 | releases. For issues that are not backported given an older release, | ||
93 | Community LTS trees and branches exist where community members share | ||
94 | patches for older releases. However, these types of patches do not go | ||
95 | through the same release process as do point releases. You can find more | ||
96 | information about stable branch maintenance at | ||
97 | https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance. | ||
98 | |||
99 | Testing and Quality Assurance | ||
100 | ============================= | ||
101 | |||
102 | Part of the Yocto Project development and release process is quality | ||
103 | assurance through the execution of test strategies. Test strategies | ||
104 | provide the Yocto Project team a way to ensure a release is validated. | ||
105 | Additionally, because the test strategies are visible to you as a | ||
106 | developer, you can validate your projects. This section overviews the | ||
107 | available test infrastructure used in the Yocto Project. For information | ||
108 | on how to run available tests on your projects, see the | ||
109 | ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" | ||
110 | section in the Yocto Project Development Tasks Manual. | ||
111 | |||
112 | The QA/testing infrastructure is woven into the project to the point | ||
113 | where core developers take some of it for granted. The infrastructure | ||
114 | consists 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 | |||
154 | Originally, much of this testing was done manually. However, significant | ||
155 | effort has been made to automate the tests so that more people can use | ||
156 | them and the Yocto Project development team can run them faster and more | ||
157 | efficiently. | ||
158 | |||
159 | The Yocto Project's main Autobuilder (https://autobuilder.yoctoproject.org/) | ||
160 | publicly tests each Yocto Project release's code in the | ||
161 | :term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing | ||
162 | occurs for both the current state of the "master" branch and also for | ||
163 | submitted patches. Testing for submitted patches usually occurs in the | ||
164 | "ross/mut" branch in the ``poky-contrib`` repository (i.e. the | ||
165 | master-under-test branch) or in the "master-next" branch in the ``poky`` | ||
166 | repository. | ||
167 | |||
168 | .. note:: | ||
169 | |||
170 | You can find all these branches in the Yocto Project | ||
171 | Source Repositories | ||
172 | . | ||
173 | |||
174 | Testing within these public branches ensures in a publicly visible way | ||
175 | that all of the main supposed architectures and recipes in OE-Core | ||
176 | successfully build and behave properly. | ||
177 | |||
178 | Various 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 | ||
181 | process of a release. Complete testing and validation for a release | ||
182 | takes 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 | |||
191 | Finally, in addition to the Autobuilder's tests, the Yocto Project QA | ||
192 | team also performs testing on a variety of platforms, which includes | ||
193 | actual hardware, to ensure expected results. | ||