diff options
Diffstat (limited to 'poky/documentation/ref-manual/ref-release-process.xml')
| -rw-r--r-- | poky/documentation/ref-manual/ref-release-process.xml | 255 |
1 files changed, 255 insertions, 0 deletions
diff --git a/poky/documentation/ref-manual/ref-release-process.xml b/poky/documentation/ref-manual/ref-release-process.xml new file mode 100644 index 000000000..c665cd938 --- /dev/null +++ b/poky/documentation/ref-manual/ref-release-process.xml @@ -0,0 +1,255 @@ +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > + +<chapter id='ref-release-process'> +<title>Yocto Project Releases and the Stable Release Process</title> + +<para> + The Yocto Project release process is predictable and consists of both + major and minor (point) releases. + This brief chapter provides information on how releases are named, their + life cycle, and their stability. +</para> + +<section id='major-and-minor-release-cadence'> + <title>Major and Minor Release Cadence</title> + + <para> + The Yocto Project delivers major releases (e.g. &DISTRO;) using a six + month cadence roughly timed each April and October of the year. + Following are examples of some major YP releases with their codenames + also shown. + See the + "<link linkend='major-release-codenames'>Major Release Codenames</link>" + section for information on codenames used with major releases. + <literallayout class='monospaced'> + 2.2 (Morty) + 2.1 (Krogoth) + 2.0 (Jethro) + </literallayout> + While the cadence is never perfect, this timescale facilitates + regular releases that have strong QA cycles while not overwhelming + users with too many new releases. + The cadence is predictable and avoids many major holidays in various + geographies. + </para> + + <para> + The Yocto project delivers minor (point) releases on an unscheduled + basis and are usually driven by the accumulation of enough significant + fixes or enhancements to the associated major release. + Following are some example past point releases: + <literallayout class='monospaced'> + 2.1.1 + 2.1.2 + 2.2.1 + </literallayout> + The point release indicates a point in the major release branch where + a full QA cycle and release process validates the content of the new + branch. + <note> + Realize that there can be patches merged onto the stable release + branches as and when they become available. + </note> + </para> +</section> + +<section id='major-release-codenames'> + <title>Major Release Codenames</title> + + <para> + Each major release receives a codename that identifies the release in + the + <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>. + The concept is that branches of + <link linkend='metadata'>Metadata</link> + with the same codename are likely to be compatible and thus + work together. + <note> + Codenames are associated with major releases because a Yocto + Project release number (e.g. &DISTRO;) could conflict with + a given layer or company versioning scheme. + Codenames are unique, interesting, and easily identifiable. + </note> + Releases are given a nominal release version as well but the codename + is used in repositories for this reason. + You can find information on Yocto Project releases and codenames at + <ulink url='https://wiki.yoctoproject.org/wiki/Releases'></ulink>. + </para> +</section> + +<section id='stable-release-process'> + <title>Stable Release Process</title> + + <para> + Once released, the release enters the stable release process at which + time a person is assigned as the maintainer for that stable release. + This maintainer monitors activity for the release by investigating + and handling nominated patches and backport activity. + Only fixes and enhancements that have first been applied on the + "master" branch (i.e. the current, in-development branch) are + considered for backporting to a stable release. + <note> + The current Yocto Project policy regarding backporting is to + consider bug fixes and security fixes only. + Policy dictates that features are not backported to a stable + release. + This policy means generic recipe version upgrades are unlikely to + be accepted for backporting. + The exception to this policy occurs when a strong reason exists + such as the fix happens to also be the preferred upstream approach. + </note> + </para> + + <para> + Stable release branches have strong maintenance for about a year after + their initial release. + Should significant issues be found for any release regardless of its + age, fixes could be backported to older releases. + For issues that are not backported given an older release, + Community LTS trees and branches exist where + community members share patches for older releases. + However, these types of patches do not go through the same release + process as do point releases. + You can find more information about stable branch maintenance at + <ulink url='https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance'></ulink>. + </para> +</section> + +<section id='testing-and-quality-assurance'> + <title>Testing and Quality Assurance</title> + + <para> + Part of the Yocto Project development and release process is quality + assurance through the execution of test strategies. + Test strategies provide the Yocto Project team a way to ensure a + release is validated. + Additionally, because the test strategies are visible to you as a + developer, you can validate your projects. + This section overviews the available test infrastructure used in the + Yocto Project. + For information on how to run available tests on your projects, see the + "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>" + section in the Yocto Project Development Tasks Manual. + </para> + + <para> + The QA/testing infrastructure is woven into the project to the point + where core developers take some of it for granted. + The infrastructure consists of the following pieces: + <itemizedlist> + <listitem><para> + <filename>bitbake-selftest</filename>: + A standalone command that runs unit tests on key pieces of + BitBake and its fetchers. + </para></listitem> + <listitem><para> + <link linkend='ref-classes-sanity'><filename>sanity.bbclass</filename></link>: + This automatically included class checks the build environment + for missing tools (e.g. <filename>gcc</filename>) or common + misconfigurations such as + <link linkend='var-MACHINE'><filename>MACHINE</filename></link> + set incorrectly. + </para></listitem> + <listitem><para> + <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>: + This class checks the generated output from builds for sanity. + For example, if building for an ARM target, did the build + produce ARM binaries. + If, for example, the build produced PPC binaries then there + is a problem. + </para></listitem> + <listitem><para> + <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>: + This class performs runtime testing of images after they are + built. + The tests are usually used with + <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU</ulink> + to boot the images and check the combined runtime result + boot operation and functions. + However, the test can also use the IP address of a machine to + test. + </para></listitem> + <listitem><para> + <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'><filename>ptest</filename></ulink>: + Runs tests against packages produced during the build for a + given piece of software. + The test allows the packages to be be run within a target + image. + </para></listitem> + <listitem><para> + <filename>oe-selftest</filename>: + Tests combination BitBake invocations. + These tests operate outside the OpenEmbedded build system + itself. + The <filename>oe-selftest</filename> can run all tests by + default or can run selected tests or test suites. + <note> + Running <filename>oe-selftest</filename> requires + host packages beyond the "Essential" grouping. + See the + "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>" + section for more information. + </note> + </para></listitem> + </itemizedlist> + </para> + + <para> + Originally, much of this testing was done manually. + However, significant effort has been made to automate the tests so + that more people can use them and the Yocto Project development team + can run them faster and more efficiently. + </para> + + <para> + The Yocto Project's main Autobuilder + (<filename>autobuilder.yoctoproject.org</filename>) publicly tests + each Yocto Project release's code in the + <link linkend='oe-core'>OE-Core</link>, Poky, and BitBake + repositories. + The testing occurs for both the current state of the + "master" branch and also for submitted patches. + Testing for submitted patches usually occurs in the + "ross/mut" branch in the <filename>poky-contrib</filename> repository + (i.e. the master-under-test branch) or in the "master-next" branch + in the <filename>poky</filename> repository. + <note> + You can find all these branches in the Yocto Project + <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>. + </note> + Testing within these public branches ensures in a publicly visible way + that all of the main supposed architectures and recipes in OE-Core + successfully build and behave properly. + </para> + + <para> + Various features such as <filename>multilib</filename>, sub + architectures (e.g. <filename>x32</filename>, + <filename>poky-tiny</filename>, <filename>musl</filename>, + <filename>no-x11</filename> and and so forth), + <filename>bitbake-selftest</filename>, and + <filename>oe-selftest</filename> are tested as part of + the QA process of a release. + Complete testing and validation for a release takes the Autobuilder + workers several hours. + <note> + The Autobuilder workers are non-homogeneous, which means regular + testing across a variety of Linux distributions occurs. + The Autobuilder is limited to only testing QEMU-based setups and + not real hardware. + </note> + </para> + + <para> + Finally, in addition to the Autobuilder's tests, the Yocto Project + QA team also performs testing on a variety of platforms, which includes + actual hardware, to ensure expected results. + </para> +</section> + +</chapter> +<!-- +vim: expandtab tw=80 ts=4 +--> |
