diff options
Diffstat (limited to 'documentation/ref-manual/release-process.rst')
-rw-r--r-- | documentation/ref-manual/release-process.rst | 122 |
1 files changed, 75 insertions, 47 deletions
diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst index ed5a09a55d..920794679d 100644 --- a/documentation/ref-manual/release-process.rst +++ b/documentation/ref-manual/release-process.rst | |||
@@ -14,14 +14,13 @@ Major and Minor Release Cadence | |||
14 | 14 | ||
15 | The Yocto Project delivers major releases (e.g. &DISTRO;) using a six | 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. | 16 | month cadence roughly timed each April and October of the year. |
17 | Following are examples of some major YP releases with their codenames | 17 | Here are examples of some major YP releases with their codenames |
18 | also shown. See the "`Major Release | 18 | also shown. See the ":ref:`ref-manual/release-process:major release codenames`" |
19 | Codenames <#major-release-codenames>`__" section for information on | 19 | section for information on codenames used with major releases. |
20 | codenames used with major releases. | ||
21 | 20 | ||
22 | - 2.2 (Morty) | 21 | - 4.1 ("Langdale") |
23 | - 2.1 (Krogoth) | 22 | - 4.0 ("Kirkstone") |
24 | - 2.0 (Jethro) | 23 | - 3.4 ("Honister") |
25 | 24 | ||
26 | While the cadence is never perfect, this timescale facilitates | 25 | While the cadence is never perfect, this timescale facilitates |
27 | regular releases that have strong QA cycles while not overwhelming users | 26 | regular releases that have strong QA cycles while not overwhelming users |
@@ -30,12 +29,12 @@ major holidays in various geographies. | |||
30 | 29 | ||
31 | The Yocto project delivers minor (point) releases on an unscheduled | 30 | The Yocto project delivers minor (point) releases on an unscheduled |
32 | basis and are usually driven by the accumulation of enough significant | 31 | basis and are usually driven by the accumulation of enough significant |
33 | fixes or enhancements to the associated major release. Following are | 32 | fixes or enhancements to the associated major release. |
34 | some example past point releases: | 33 | Some example past point releases are: |
35 | 34 | ||
36 | - 2.1.1 | 35 | - 4.1.3 |
37 | - 2.1.2 | 36 | - 4.0.8 |
38 | - 2.2.1 | 37 | - 3.4.4 |
39 | 38 | ||
40 | The point release | 39 | The point release |
41 | indicates a point in the major release branch where a full QA cycle and | 40 | indicates a point in the major release branch where a full QA cycle and |
@@ -63,8 +62,10 @@ codename are likely to be compatible and thus work together. | |||
63 | 62 | ||
64 | Releases are given a nominal release version as well but the codename is | 63 | 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 | 64 | used in repositories for this reason. You can find information on Yocto |
66 | Project releases and codenames at | 65 | Project releases and codenames at :yocto_wiki:`/Releases`. |
67 | :yocto_wiki:`/Releases`. | 66 | |
67 | Our :doc:`/migration-guides/index` detail how to migrate from one release of | ||
68 | the Yocto Project to the next. | ||
68 | 69 | ||
69 | Stable Release Process | 70 | Stable Release Process |
70 | ====================== | 71 | ====================== |
@@ -83,18 +84,54 @@ stable release. | |||
83 | bug fixes and security fixes only. Policy dictates that features are | 84 | bug fixes and security fixes only. Policy dictates that features are |
84 | not backported to a stable release. This policy means generic recipe | 85 | not backported to a stable release. This policy means generic recipe |
85 | version upgrades are unlikely to be accepted for backporting. The | 86 | version upgrades are unlikely to be accepted for backporting. The |
86 | exception to this policy occurs when a strong reason exists such as | 87 | exception to this policy occurs when there is a strong reason such as |
87 | the fix happens to also be the preferred upstream approach. | 88 | the fix happens to also be the preferred upstream approach. |
88 | 89 | ||
89 | Stable release branches have strong maintenance for about a year after | 90 | .. _ref-long-term-support-releases: |
90 | their initial release. Should significant issues be found for any | 91 | |
91 | release regardless of its age, fixes could be backported to older | 92 | Long Term Support Releases |
92 | releases. For issues that are not backported given an older release, | 93 | ========================== |
93 | Community LTS trees and branches exist where community members share | 94 | |
94 | patches for older releases. However, these types of patches do not go | 95 | While stable releases are supported for a duration of seven months, |
95 | through the same release process as do point releases. You can find more | 96 | some specific ones are now supported for a longer period by the Yocto |
96 | information about stable branch maintenance at | 97 | Project, and are called Long Term Support (:term:`LTS`) releases. |
97 | :yocto_wiki:`/Stable_branch_maintenance`. | 98 | |
99 | When significant issues are found, :term:`LTS` releases allow to publish | ||
100 | fixes not only for the current stable release, but also to the | ||
101 | :term:`LTS` releases that are still supported. Older stable releases which | ||
102 | have reached their End of Life (EOL) won't receive such updates. | ||
103 | |||
104 | This started with version 3.1 ("Dunfell"), released in April 2020, which | ||
105 | the project initially committed to supporting for two years, but this duration | ||
106 | was later extended to four years. Similarly, the following :term:`LTS` release, | ||
107 | version 4.0 ("Kirkstone"), was released two years later in May 2022 and the | ||
108 | project committed to supporting it for four years too. | ||
109 | |||
110 | Therefore, a new :term:`LTS` release is made every two years and is supported | ||
111 | for four years. This offers more stability to project users and leaves more | ||
112 | time to upgrade to the following :term:`LTS` release. | ||
113 | |||
114 | See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management | ||
115 | of stable and :term:`LTS` releases. | ||
116 | |||
117 | .. image:: svg/releases.* | ||
118 | :width: 100% | ||
119 | |||
120 | .. note:: | ||
121 | |||
122 | In some circumstances, a layer can be created by the community in order to | ||
123 | add a specific feature or support a new version of some package for an :term:`LTS` | ||
124 | release. This is called a :term:`Mixin` layer. These are thin and specific | ||
125 | purpose layers which can be stacked with an :term:`LTS` release to "mix" a specific | ||
126 | feature into that build. These are created on an as-needed basis and | ||
127 | maintained by the people who need them. | ||
128 | |||
129 | Policies on testing these layers depend on how widespread their usage is and | ||
130 | determined on a case-by-case basis. You can find some :term:`Mixin` layers in the | ||
131 | :yocto_git:`meta-lts-mixins </meta-lts-mixins>` repository. While the Yocto | ||
132 | Project provides hosting for those repositories, it does not provides | ||
133 | testing on them. Other :term:`Mixin` layers may be released elsewhere by the wider | ||
134 | community. | ||
98 | 135 | ||
99 | Testing and Quality Assurance | 136 | Testing and Quality Assurance |
100 | ============================= | 137 | ============================= |
@@ -106,7 +143,7 @@ Additionally, because the test strategies are visible to you as a | |||
106 | developer, you can validate your projects. This section overviews the | 143 | developer, you can validate your projects. This section overviews the |
107 | available test infrastructure used in the Yocto Project. For information | 144 | available test infrastructure used in the Yocto Project. For information |
108 | on how to run available tests on your projects, see the | 145 | on how to run available tests on your projects, see the |
109 | ":ref:`dev-manual/common-tasks:performing automated runtime testing`" | 146 | ":ref:`dev-manual/runtime-testing:performing automated runtime testing`" |
110 | section in the Yocto Project Development Tasks Manual. | 147 | section in the Yocto Project Development Tasks Manual. |
111 | 148 | ||
112 | The QA/testing infrastructure is woven into the project to the point | 149 | The QA/testing infrastructure is woven into the project to the point |
@@ -116,58 +153,49 @@ consists of the following pieces: | |||
116 | - ``bitbake-selftest``: A standalone command that runs unit tests on | 153 | - ``bitbake-selftest``: A standalone command that runs unit tests on |
117 | key pieces of BitBake and its fetchers. | 154 | key pieces of BitBake and its fetchers. |
118 | 155 | ||
119 | - :ref:`sanity.bbclass <ref-classes-sanity>`: This automatically | 156 | - :ref:`ref-classes-sanity`: This automatically |
120 | included class checks the build environment for missing tools (e.g. | 157 | included class checks the build environment for missing tools (e.g. |
121 | ``gcc``) or common misconfigurations such as | 158 | ``gcc``) or common misconfigurations such as |
122 | :term:`MACHINE` set incorrectly. | 159 | :term:`MACHINE` set incorrectly. |
123 | 160 | ||
124 | - :ref:`insane.bbclass <ref-classes-insane>`: This class checks the | 161 | - :ref:`ref-classes-insane`: This class checks the |
125 | generated output from builds for sanity. For example, if building for | 162 | generated output from builds for sanity. For example, if building for |
126 | an ARM target, did the build produce ARM binaries. If, for example, | 163 | an ARM target, did the build produce ARM binaries. If, for example, |
127 | the build produced PPC binaries then there is a problem. | 164 | the build produced PPC binaries then there is a problem. |
128 | 165 | ||
129 | - :ref:`testimage.bbclass <ref-classes-testimage*>`: This class | 166 | - :ref:`ref-classes-testimage`: This class |
130 | performs runtime testing of images after they are built. The tests | 167 | performs runtime testing of images after they are built. The tests |
131 | are usually used with :doc:`QEMU </dev-manual/qemu>` | 168 | are usually used with :doc:`QEMU </dev-manual/qemu>` |
132 | to boot the images and check the combined runtime result boot | 169 | to boot the images and check the combined runtime result boot |
133 | operation and functions. However, the test can also use the IP | 170 | operation and functions. However, the test can also use the IP |
134 | address of a machine to test. | 171 | address of a machine to test. |
135 | 172 | ||
136 | - :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`: | 173 | - :ref:`ptest <dev-manual/packages:testing packages with ptest>`: |
137 | Runs tests against packages produced during the build for a given | 174 | 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 | 175 | piece of software. The test allows the packages to be run within a |
139 | target image. | 176 | target image. |
140 | 177 | ||
141 | - ``oe-selftest``: Tests combination BitBake invocations. These tests | 178 | - ``oe-selftest``: Tests combinations of BitBake invocations. These tests |
142 | operate outside the OpenEmbedded build system itself. The | 179 | operate outside the OpenEmbedded build system itself. The |
143 | ``oe-selftest`` can run all tests by default or can run selected | 180 | ``oe-selftest`` can run all tests by default or can run selected |
144 | tests or test suites. | 181 | tests or test suites. |
145 | 182 | ||
146 | .. note:: | ||
147 | |||
148 | Running ``oe-selftest`` requires host packages beyond the "Essential" | ||
149 | grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host` | ||
150 | section for more information. | ||
151 | |||
152 | Originally, much of this testing was done manually. However, significant | 183 | Originally, much of this testing was done manually. However, significant |
153 | effort has been made to automate the tests so that more people can use | 184 | effort has been made to automate the tests so that more people can use |
154 | them and the Yocto Project development team can run them faster and more | 185 | them and the Yocto Project development team can run them faster and more |
155 | efficiently. | 186 | efficiently. |
156 | 187 | ||
157 | The Yocto Project's main Autobuilder (&YOCTO_AB_URL;) | 188 | The Yocto Project's main Autobuilder (&YOCTO_AB_URL;) publicly tests each Yocto |
158 | publicly tests each Yocto Project release's code in the | 189 | Project release's code in the :oe_git:`openembedded-core </openembedded-core>`, |
159 | :term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing | 190 | :yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The |
160 | occurs for both the current state of the "master" branch and also for | 191 | testing occurs for both the current state of the "master" branch and also for |
161 | submitted patches. Testing for submitted patches usually occurs in the | 192 | submitted patches. Testing for submitted patches usually occurs in the |
162 | "ross/mut" branch in the ``poky-contrib`` repository (i.e. the | 193 | in the "master-next" branch in the :yocto_git:`poky </poky>` repository. |
163 | master-under-test branch) or in the "master-next" branch in the ``poky`` | ||
164 | repository. | ||
165 | 194 | ||
166 | .. note:: | 195 | .. note:: |
167 | 196 | ||
168 | You can find all these branches in the Yocto Project | 197 | You can find all these branches in the |
169 | Source Repositories | 198 | :ref:`overview-manual/development-environment:yocto project source repositories`. |
170 | . | ||
171 | 199 | ||
172 | Testing within these public branches ensures in a publicly visible way | 200 | Testing within these public branches ensures in a publicly visible way |
173 | that all of the main supposed architectures and recipes in OE-Core | 201 | that all of the main supposed architectures and recipes in OE-Core |