mirror of https://github.com/django/django.git
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:
parent
937213c2c3
commit
67f7756000
|
@ -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:
|
||||
|
|
Loading…
Reference in New Issue