innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/internals/release-process.txt
View File

@ -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: