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

Fixed #23414 -- Updated version numbers in release process doc. 

Thanks jaap3 for the report.
This commit is contained in:
Tim Graham 2014-09-05 15:41:37 -04:00
parent 7a259008a7
commit 5c5011ce68
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -38,8 +38,8 @@ security purposes, please see :doc:`our security policies <security>`.
.. glossary:: .. glossary::
Major release Major release
Major releases (1.5, 1.6, etc.) will happen roughly every nine months -- see Major releases (A.B, A.B+1, etc.) will happen roughly every nine months --
`release process`_, below for details. These releases will contain new see `release process`_, below for details. These releases will contain new
features, improvements to existing features, and such. features, improvements to existing features, and such.
.. _internal-release-deprecation-policy: .. _internal-release-deprecation-policy:
@ -63,8 +63,8 @@ security purposes, please see :doc:`our security policies <security>`.
* Django 1.9 will remove the feature outright. * Django 1.9 will remove the feature outright.
Minor release Minor release
Minor releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to Minor releases (A.B.C, etc.) will be issued as needed, often to fix security
fix security issues. issues.
These releases will be 100% compatible with the associated major release, These releases will be 100% compatible with the associated major release,
unless this is impossible for security reasons or to prevent data loss. unless this is impossible for security reasons or to prevent data loss.
@ -107,20 +107,20 @@ varying levels:
regressions is much less of a concern. regressions is much less of a 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.6 and 1.7. At this point in time: Django 1.7 and 1.8. At this point in time:
* Features will be added to development master, to be released as Django 1.7. * Features will be added to development master, to be released as Django 1.8.
* Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and * Critical bug fixes will be applied to the ``stable/1.7.x`` branch, and
released as 1.6.1, 1.6.2, etc. released as 1.7.1, 1.7.2, etc.
* Security fixes and bug fixes for data loss issues will be applied to * Security fixes and bug fixes for data loss issues will be applied to
``master`` and to the ``stable/1.6.x``, ``stable/1.5.x``, and ``master`` and to the ``stable/1.7.x``, ``stable/1.6.x``, and
``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.6.1``, ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.7.1``,
``1.5.1``, ``1.4.1``, etc. ``1.6.1``, ``1.4.1``, etc.
* Documentation fixes will be applied to master, and, if easily backported, to * Documentation fixes will be applied to master, and, if easily backported, to
the ``1.6.x`` branch. the ``1.7.x`` and ``1.6.x`` branches.
.. _lts-releases: .. _lts-releases:
@ -141,8 +141,8 @@ The follow releases have been designated for long-term support:
Release process Release process
=============== ===============
Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.) Django uses a time-based release schedule, with major (i.e. 1.8, 1.9, 2.0,
releases every nine months, or more, depending on features. etc.) releases every nine months, or more, depending on features.
After each release, and after a suitable cooling-off period of a few weeks, After each release, and after a suitable cooling-off period of a few weeks,
core developers will examine the landscape and announce a timeline for the core developers will examine the landscape and announce a timeline for the
@ -211,10 +211,10 @@ in the ``A.B+1`` cycle.
Bug-fix releases Bug-fix releases
---------------- ----------------
After a major release (e.g. 1.6), the previous release will go into bugfix After a major release (e.g. A.B), the previous release will go into bugfix
mode. mode.
The branch for the previous major release (e.g. ``stable/1.5.x``) will include The branch for the previous major release (e.g. ``stable/A.B-1.x``) will include
bugfixes. Critical bugs fixed on master must *also* be fixed on the bugfix bugfixes. Critical bugs fixed on master must *also* be fixed on the bugfix
branch; this means that commits need to cleanly separate bug fixes from feature branch; this means that commits need to cleanly separate bug fixes from feature
additions. The developer who commits a fix to master will be responsible for additions. The developer who commits a fix to master will be responsible for