Fixed #16469 -- Improved documentation of Django internals, including the new backport policy. Many thanks to Aymeric Augustin.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16548 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 44 insertions, 31 deletions

diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index 2a56f0be92..47fff21025 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -7,30 +7,30 @@ Django's release process
 Official releases
 =================
 
-Django's release numbering works as follows:
+Since version 1.0, Django's release numbering works as follows:
 
     * Versions are numbered in the form ``A.B`` or ``A.B.C``.
 
     * ``A`` is the *major version* number, which is only incremented for major
       changes to Django, and these changes are not necessarily
-      backwards-compatible. That is, code you wrote for Django 6.0 may break
-      when we release Django 7.0.
+      backwards-compatible. That is, code you wrote for Django 1.2 may break
+      when we release Django 2.0.
 
     * ``B`` is the *minor version* number, which is incremented for large yet
-      backwards compatible changes.  Code written for Django 6.4 will continue
-      to work under Django 6.5.
+      backwards compatible changes.  Code written for Django 1.2 will continue
+      to work under Django 1.3. Exceptions to this rule will be listed in the
+      release notes.
 
-    * ``C`` is the *micro version* number which, is incremented for bug and
-      security fixes.  A new micro-release will always be 100%
-      backwards-compatible with the previous micro-release.
+    * ``C`` is the *micro version* number, which is incremented for bug and
+      security fixes. A new micro-release will be 100% backwards-compatible with
+      the previous micro-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.
 
     * In some cases, we'll make alpha, beta, or release candidate releases.
       These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth``
       alpha/beta/release candidate of version ``A.B``.
 
-An exception to this version numbering scheme is the pre-1.0 Django code.
-There's no guarantee of backwards-compatibility until the 1.0 release.
-
 In Subversion, each Django release will be tagged under ``tags/releases``.  If
 it's necessary to release a bug fix release or a security release that doesn't
 come from the trunk, we'll copy that tag to ``branches/releases`` to make the
@@ -75,9 +75,9 @@ Micro releases
 Micro releases (1.0.1, 1.0.2, 1.1.1, etc.) will be issued at least once half-way
 between minor releases, and probably more often as needed.
 
-These releases will always be 100% compatible with the associated minor release
--- the answer to "should I upgrade to the latest micro release?" will always be
-"yes."
+These releases will be 100% compatible with the associated minor release, unless
+this is impossible for security reasons. So the answer to "should I upgrade to
+the latest micro release?" will always be "yes."
 
 Each minor release of Django will have a "release maintainer" appointed. This
 person will be responsible for making sure that bug fixes are applied to both
@@ -93,8 +93,20 @@ varying levels:
     * The current development trunk will get new features and bug fixes
       requiring major refactoring.
 
-    * All bug fixes applied to the trunk will also be applied to the last
-      minor release, to be released as the next micro release.
+    * Patches applied to the trunk will also be applied to the last minor
+      release, to be released as the next micro release, when they fix critical
+      problems:
+
+      * Security issues.
+
+      * Data-loss bugs.
+
+      * Crashing bugs.
+
+      * Major functionality bugs in newly-introduced features.
+
+      The rule of thumb is that fixes will be backported to the last minor
+      release for bugs that would have prevented a release in the first place.
 
     * Security fixes will be applied to the current trunk and the previous two
       minor releases.
@@ -104,12 +116,12 @@ Django 1.3 and 1.4. At this point in time:
 
     * Features will be added to development trunk, to be released as Django 1.4.
 
-    * Bug fixes will be applied to a ``1.3.X`` branch, and released as 1.3.1,
-      1.3.2, etc.
+    * Critical bug fixes will be applied to a ``1.3.X`` branch, and released as
+      1.3.1, 1.3.2, etc.
 
-    * Security releases will be applied to trunk, a ``1.3.X`` branch and a
-      ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``,
-      ``1.2.1``, etc.
+    * Security fixes will be applied to trunk, a ``1.3.X`` branch and a
+      ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``,
+      etc.
 
 .. _release-process:
 
@@ -119,11 +131,11 @@ Release process
 Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
 releases every nine months, or more, depending on features.
 
-After each previous release (and after a suitable cooling-off period of a week
-or two), the core development team will examine the landscape and announce a
-timeline for the next release. Most releases will be scheduled in the 6-9 month
-range, but if we have bigger features to development we might schedule a longer
-period to allow for more ambitious work.
+After each release, and after a suitable cooling-off period of a few weeks, the
+core development team will examine the landscape and announce a timeline for the
+next release. Most releases will be scheduled in the 6-9 month range, but if we
+have bigger features to development we might schedule a longer period to allow
+for more ambitious work.
 
 Release cycle
 -------------
@@ -174,10 +186,11 @@ and an rc complete with string freeze two weeks before the end of the schedule.
 Bug-fix releases
 ----------------
 
-After a minor release (i.e 1.1), the previous release will go into bug-fix mode.
+After a minor release (e.g. 1.1), the previous release will go into bug-fix
+mode.
 
 A branch will be created of the form ``branches/releases/1.0.X`` to track
-bug-fixes to the previous release. When possible, bugs fixed on trunk must
+bug-fixes to the previous release. Critical bugs fixed on trunk must
 *also* be fixed on the bug-fix branch; this means that commits need to cleanly
 separate bug fixes from feature additions. The developer who commits a fix to
 trunk will be responsible for also applying the fix to the current bug-fix
@@ -194,9 +207,9 @@ development will be happening in a bunch of places:
     * On trunk, development towards 1.2 proceeds with small additions, bugs
       fixes, etc. being checked in daily.
 
-    * On the branch "branches/releases/1.1.X", bug fixes found in the 1.1
-      release are checked in as needed. At some point, this branch will be
-      released as "1.1.1", "1.1.2", etc.
+    * On the branch "branches/releases/1.1.X", fixes for critical bugs found in
+      the 1.1 release are checked in as needed. At some point, this branch will
+      be released as "1.1.1", "1.1.2", etc.
 
     * On the branch "branches/releases/1.0.X", security fixes are made if
       needed and released as "1.0.2", "1.0.3", etc.