<!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
-->
