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
+ .
+
+
+
+
+