Edited release-process.txt changes from [17300]

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17310 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Adrian Holovaty 2011-12-30 20:39:08 +00:00
parent 937213c2c3
commit 67f7756000
1 changed files with 7 additions and 7 deletions

View File

@ -111,12 +111,12 @@ varying levels:
* Security fixes will be applied to the current trunk and the previous two * Security fixes will be applied to the current trunk and the previous two
minor releases. minor releases.
* Documentation fixes will generally be more freely backported to the last * Documentation fixes generally will be more freely backported to the last
release branch (at the discretion of the committer), and don't need to meet release branch, at the discretion of the committer, and they don't need to
the "critical fixes only" bar as it's highly advantageous to have the docs meet the "critical fixes only" bar. That's because it's highly advantageous
for the last release be up-to-date and correct, and the downside of to have the docs for the last release be up-to-date and correct, and the
backporting (risk of introducing regressions) is much less of a concern downside of backporting (risk of introducing regressions) is much less of a
with doc fixes. concern.
As a concrete example, consider a moment in time halfway between the release of 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: 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``, ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``,
etc. 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. the ``1.3.X`` branch.
.. _release-process: .. _release-process: