summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--documentation/mega-manual/mega-manual.xml3
-rw-r--r--documentation/ref-manual/ref-manual.xml2
-rw-r--r--documentation/ref-manual/ref-release-process.xml123
3 files changed, 128 insertions, 0 deletions
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
@@ -215,6 +215,9 @@
215 xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/technical-details.xml"/> 215 xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/technical-details.xml"/>
216 216
217 <xi:include 217 <xi:include
218 xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/ref-release-process.xml"/>
219
220 <xi:include
218 xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/migration.xml"/> 221 xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/migration.xml"/>
219 222
220 <xi:include 223 <xi:include
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 @@
162 162
163 <xi:include href="technical-details.xml"/> 163 <xi:include href="technical-details.xml"/>
164 164
165 <xi:include href="ref-release-process.xml"/>
166
165 <xi:include href="migration.xml"/> 167 <xi:include href="migration.xml"/>
166 168
167 <xi:include href="ref-structure.xml"/> 169 <xi:include href="ref-structure.xml"/>
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 @@
1<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<chapter id='ref-release-process'>
6<title>Yocto Project Releases and the Stable Release Process</title>
7
8<para>
9 The Yocto Project release process is predictable and consists of both
10 major and minor (point) releases.
11 This brief chapter provides information on how releases are named, their
12 life cycle, and their stability.
13</para>
14
15<section id='major-and-minor-release-cadence'>
16 <title>Major and Minor Release Cadence</title>
17
18 <para>
19 The Yocto Project delivers major releases (e.g. &DISTRO;) using a six
20 month cadence roughly timed each April and October of the year.
21 Following are examples of some major YP releases with their codenames
22 also shown.
23 See the
24 "<link linkend='major-release-codenames'>Major Release Codenames</link>"
25 section for information on codenames used with major releases.
26 <literallayout class='monospaced'>
27 2.2 (Morty)
28 2.1 (Krogoth)
29 2.0 (Jethro)
30 </literallayout>
31 While the cadence is never perfect, this timescale facilitates
32 regular releases that have strong QA cycles while not overwhelming
33 users with too many new releases.
34 The cadence is predictable and avoids many major holidays in various
35 geographies.
36 </para>
37
38 <para>
39 The Yocto project delivers minor (point) releases on an unscheduled
40 basis and are usually driven by the accumulation of enough significant
41 fixes or enhancements to the associated major release.
42 Following are some example past point releases:
43 <literallayout class='monospaced'>
44 2.1.1
45 2.1.2
46 2.2.1
47 </literallayout>
48 The point release indicates a point in the major release branch where
49 a full QA cycle and release process validates the content of the new
50 branch.
51 <note>
52 Realize that there can be patches merged onto the stable release
53 branches as and when they become available.
54 </note>
55 </para>
56</section>
57
58<section id='major-release-codenames'>
59 <title>Major Release Codenames</title>
60
61 <para>
62 Each major release receives a codename that identifies the release in
63 the
64 <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
65 The concept is that branches of
66 <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
67 with the same codename are likely to be compatible and thus
68 work together.
69 <note>
70 Codenames are associated with major releases because a Yocto
71 Project release number (e.g. &DISTRO;) could conflict with
72 a given layer or company versioning scheme.
73 Codenames are unique, interesting, and easily identifiable.
74 </note>
75 Releases are given a nominal release version as well but the codename
76 is used in repositories for this reason.
77 You can find information on Yocto Project releases and codenames at
78 <ulink url='https://wiki.yoctoproject.org/wiki/Releases'></ulink>.
79 </para>
80</section>
81
82<section id='stable-release-process'>
83 <title>Stable Release Process</title>
84
85 <para>
86 Once released, the release enters the stable release process at which
87 time a person is assigned as the maintainer for that stable release.
88 This maintainer monitors activity for the release by investigating
89 and handling nominated patches and backport activity.
90 Only fixes and enhancements that have first been applied on the
91 "master" branch (i.e. the current, in-development branch) are
92 considered for backporting to a stable release.
93 <note>
94 The current Yocto Project policy regarding backporting is to
95 consider bug fixes and security fixes only.
96 Policy dictates that features are not backported to a stable
97 release.
98 This policy means generic recipe version upgrades are unlikely to
99 be accepted for backporting.
100 The exception to this policy occurs when a strong reason exists
101 such as the fix happens to also be the preferred upstream approach.
102 </note>
103 </para>
104
105 <para>
106 Stable release branches have strong maintenance for about a year after
107 their initial release.
108 Should significant issues be found for any release regardless of its
109 age, fixes could be backported to older releases.
110 For issues that are not backported given an older release,
111 Community LTS trees and branches exist where
112 community members share patches for older releases.
113 However, these types of patches do not go through the same release
114 process as do point releases.
115 You can find more information about stable branch maintenance at
116 <ulink url='https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance'></ulink>.
117 </para>
118</section>
119
120</chapter>
121<!--
122vim: expandtab tw=80 ts=4
123-->