From 4c1432bd0b933d86620e0c735a8a697a341c4fdc Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 13 Mar 2017 12:12:03 -0700 Subject: ref-manual: Added new "Release Process" chapter Fixes [YOCTO #10888] The YP documentation was missing information on how the major and minor (point) release process works. I added a new chapter in front of the "Maintenance" chapter that details the naming schemes, cadence, and maintenance for YP releases. (From yocto-docs rev: b486f871e1fb8a6f763510ed385f459fe215fa27) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/mega-manual/mega-manual.xml | 3 + documentation/ref-manual/ref-manual.xml | 2 + documentation/ref-manual/ref-release-process.xml | 123 +++++++++++++++++++++++ 3 files changed, 128 insertions(+) create mode 100644 documentation/ref-manual/ref-release-process.xml (limited to 'documentation') diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml index 4f03864b2d..3406ee8c12 100644 --- a/documentation/mega-manual/mega-manual.xml +++ b/documentation/mega-manual/mega-manual.xml @@ -214,6 +214,9 @@ + + diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml index 3c8e63fe22..0259f0cdfd 100644 --- a/documentation/ref-manual/ref-manual.xml +++ b/documentation/ref-manual/ref-manual.xml @@ -162,6 +162,8 @@ + + diff --git a/documentation/ref-manual/ref-release-process.xml b/documentation/ref-manual/ref-release-process.xml new file mode 100644 index 0000000000..1b337f8bd7 --- /dev/null +++ b/documentation/ref-manual/ref-release-process.xml @@ -0,0 +1,123 @@ + %poky; ] > + + +Yocto Project Releases and the Stable Release Process + + + 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. + + +
+ Major and Minor Release Cadence + + + 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 + "Major Release Codenames" + section for information on codenames used with major releases. + + 2.2 (Morty) + 2.1 (Krogoth) + 2.0 (Jethro) + + 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. + + + + 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: + + 2.1.1 + 2.1.2 + 2.2.1 + + 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. + + Realize that there can be patches merged onto the stable release + branches as and when they become available. + + +
+ +
+ Major Release Codenames + + + Each major release receives a codename that identifies the release in + the + Yocto Project Source Repositories. + The concept is that branches of + Metadata + with the same codename are likely to be compatible and thus + work together. + + 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. + + 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 + . + +
+ +
+ Stable Release Process + + + 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. + + 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. + + + + + 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 + . + +
+ + + -- cgit v1.2.3-54-g00ecf