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