From 7b9016e5a229c2269d758959e4d07a0dbe4e710f Mon Sep 17 00:00:00 2001 From: Timo Graham Date: Fri, 30 Dec 2011 15:31:09 +0000 Subject: [PATCH] [1.3.X] Fixed #17068 - Documented that documentation fixes will be more freely backported. Backport of r17300 from trunk. git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.3.X@17301 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/release-process.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index 2a56f0be92..799a59eda5 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -99,6 +99,13 @@ varying levels: * Security fixes will be applied to the current trunk and the previous two minor releases. +* Documentation fixes will generally be more freely backported to the last + release branch (at the discretion of the committer), and don't need to meet + the "critical fixes only" bar as it's highly advantageous to have the docs + for the last release be up-to-date and correct, and the downside of + backporting (risk of introducing regressions) is much less of a concern + with doc fixes. + As a concrete example, consider a moment in time halfway between the release of Django 1.3 and 1.4. At this point in time: @@ -111,6 +118,9 @@ Django 1.3 and 1.4. At this point in time: ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``, ``1.2.1``, etc. +* Documentation fixes will be applied to trunk, and if easily backported, to + the ``1.3.X`` branch. + .. _release-process: Release process