Fixed #23079 -- Added data loss issues to those that will be backported to LTS.

1 files changed, 17 insertions, 39 deletions

diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index 69d4311592..26343a1bbd 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -19,9 +19,9 @@ Since version 1.0, Django's release numbering works as follows:
 
 * ``C`` is the *minor version* number, which is incremented for bug and
   security fixes. A new minor release will be 100% backwards-compatible with
-  the previous minor release. The only exception is when a security issue
-  can't be fixed without breaking backwards-compatibility. If this happens,
-  the release notes will provide detailed upgrade instructions.
+  the previous minor release. The only exception is when a security or data loss
+  issue can't be fixed without breaking backwards-compatibility. If this
+  happens, the release notes will provide detailed upgrade instructions.
 
 * Before a new major release, we'll make alpha, beta, and release candidate
   releases. These are of the form ``A.B alpha/beta/rc N``, which means the
@@ -67,8 +67,9 @@ security purposes, please see :doc:`our security policies <security>`.
     fix security issues.
 
     These releases will be 100% compatible with the associated major release,
-    unless this is impossible for security reasons. So the answer to "should I
-    upgrade to the latest minor release?" will always be "yes."
+    unless this is impossible for security reasons or to prevent data loss.
+    So the answer to "should I upgrade to the latest minor release?" will always
+    be "yes."
 
 .. _backwards-compatibility-policy:
 
@@ -87,7 +88,7 @@ varying levels:
 
   * Security issues.
 
-  * Data-loss bugs.
+  * Data loss bugs.
 
   * Crashing bugs.
 
@@ -97,11 +98,8 @@ varying levels:
   for bugs that would have prevented a release in the first place (release
   blockers).
 
-* Security fixes will be applied to the current master, the previous two major
-  releases, and the current :ref:`LTS release <lts-releases>`.
-
-* Committers may choose to backport bugfixes at their own discretion,
-  provided they do not introduce backwards incompatibilities.
+* Security fixes and data loss bugs will be applied to the current master, the
+  last two major releases, and the current :ref:`LTS release <lts-releases>`.
 
 * Documentation fixes generally will be more freely backported to the last
   release branch. That's because it's highly advantageous to have the docs for
@@ -116,12 +114,13 @@ Django 1.6 and 1.7. At this point in time:
 * Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
   released as 1.6.1, 1.6.2, etc.
 
-* Security fixes will be applied to ``master``, to the ``stable/1.6.x``
-  branch, and to the ``stable/1.5.x`` branch. They will trigger the release of
-  ``1.6.1``, ``1.5.1``, etc.
+* Security fixes and bug fixes for data loss issues will be applied to
+  ``master`` and to the ``stable/1.6.x``, ``stable/1.5.x``, and
+  ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.6.1``,
+  ``1.5.1``, ``1.4.1``, etc.
 
 * Documentation fixes will be applied to master, and, if easily backported, to
-  the ``1.6.x`` branch. Bugfixes may also be backported.
+  the ``1.6.x`` branch.
 
 .. _lts-releases:
 
@@ -129,9 +128,9 @@ Long-term support (LTS) releases
 ================================
 
 Additionally, the Django team will occasionally designate certain releases
-to be "Long-term support" (LTS) releases. LTS releases will get security fixes
-applied for a guaranteed period of time, typically 3+ years, regardless of
-the pace of releases afterwards.
+to be "Long-term support" (LTS) releases. LTS releases will get security and
+data loss fixes applied for a guaranteed period of time, typically 3+ years,
+regardless of the pace of releases afterwards.
 
 The follow releases have been designated for long-term support:
 
@@ -220,24 +219,3 @@ bugfixes. Critical bugs fixed on master must *also* be fixed on the bugfix
 branch; this means that commits need to cleanly separate bug fixes from feature
 additions. The developer who commits a fix to master will be responsible for
 also applying the fix to the current bugfix branch.
-
-How this all fits together
---------------------------
-
-Let's look at a hypothetical example for how this all first together. Imagine,
-if you will, a point about halfway between 1.5 and 1.6. At this point,
-development will be happening in a bunch of places:
-
-* On master, development towards 1.6 proceeds with small additions, bugs
-  fixes, etc. being checked in daily.
-
-* On the branch ``stable/1.5.x``, fixes for critical bugs found in
-  the 1.5 release are checked in as needed. At some point, this branch will
-  be released as "1.5.1", "1.5.2", etc.
-
-* On the branch ``stable/1.4.x``, security fixes are made if
-  needed and released as "1.4.2", "1.4.3", etc.
-
-* Development of major features is done in branches in forks of the main
-  repository. These branches will be merged into ``master`` before "1.6
-  alpha 1".