From 67f7756000aab9cf1042fa155abe9b5d1020b117 Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Fri, 30 Dec 2011 20:39:08 +0000 Subject: [PATCH] Edited release-process.txt changes from [17300] git-svn-id: http://code.djangoproject.com/svn/django/trunk@17310 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/release-process.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index e82bdc2c4c2..8ead4d7ae72 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -111,12 +111,12 @@ 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. +* Documentation fixes generally will be more freely backported to the last + release branch, at the discretion of the committer, and they don't need to + meet the "critical fixes only" bar. That's because 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. 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: @@ -130,7 +130,7 @@ Django 1.3 and 1.4. At this point in time: ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``, etc. -* Documentation fixes will be applied to trunk, and if easily backported, to +* Documentation fixes will be applied to trunk, and, if easily backported, to the ``1.3.X`` branch. .. _release-process: