[gnome-continuous-yocto/gnomeostree-3.28-rocko: 5302/8267] ref-manual: Added new "Release Process" chapter

[Emmanuele Bassi <ebassi src gnome org>]

commit 4c1432bd0b933d86620e0c735a8a697a341c4fdc
Author: Scott Rifenbark <srifenbark gmail com>
Date:   Mon Mar 13 12:12:03 2017 -0700

    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 <srifenbark gmail com>
    Signed-off-by: Richard Purdie <richard purdie linuxfoundation org>

 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(+), 0 deletions(-)
---
diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml
index 4f03864..3406ee8 100644
--- a/documentation/mega-manual/mega-manual.xml
+++ b/documentation/mega-manual/mega-manual.xml
@@ -215,6 +215,9 @@
         xmlns:xi="http://www.w3.org/2003/XInclude"; href="../ref-manual/technical-details.xml"/>
 
     <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude"; href="../ref-manual/ref-release-process.xml"/>
+
+    <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude"; href="../ref-manual/migration.xml"/>
 
     <xi:include
diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml
index 3c8e63f..0259f0c 100644
--- a/documentation/ref-manual/ref-manual.xml
+++ b/documentation/ref-manual/ref-manual.xml
@@ -162,6 +162,8 @@
 
     <xi:include href="technical-details.xml"/>
 
+    <xi:include href="ref-release-process.xml"/>
+
     <xi:include href="migration.xml"/>
 
     <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 0000000..1b337f8
--- /dev/null
+++ b/documentation/ref-manual/ref-release-process.xml
@@ -0,0 +1,123 @@
+<!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_DEV_URL;#yocto-project-repositories'>Yocto Project Source 
Repositories</ulink>.
+        The concept is that branches of
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        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>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->