Ticket #23414: 23414.diff

File 23414.diff, 3.5 KB (added by Tim Graham, 10 years ago)

  • docs/internals/release-process.txt 

    diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index c470273..cc79ec9 100644
    a b security purposes, please see :doc:`our security policies <security>`.  
    3838.. glossary::
    3939
    4040  Major release
    41     Major releases (1.5, 1.6, etc.) will happen roughly every nine months -- see
    42     `release process`_, below for details. These releases will contain new
     41    Major releases (A.B, A.B+1, etc.) will happen roughly every nine months --
     42    see `release process`_, below for details. These releases will contain new
    4343    features, improvements to existing features, and such.
    4444
    4545    .. _internal-release-deprecation-policy:
    … … security purposes, please see :doc:`our security policies <security>`.  
    6363    * Django 1.9 will remove the feature outright.
    6464
    6565  Minor release
    66     Minor releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
    67     fix security issues.
     66    Minor releases (A.B.C, etc.) will be issued as needed, often to fix security
     67    issues.
    6868
    6969    These releases will be 100% compatible with the associated major release,
    7070    unless this is impossible for security reasons or to prevent data loss.
    … … varying levels:  
    107107  regressions is much less of a concern.
    108108
    109109As a concrete example, consider a moment in time halfway between the release of
    110 Django 1.6 and 1.7. At this point in time:
     110Django 1.7 and 1.8. At this point in time:
    111111
    112 * Features will be added to development master, to be released as Django 1.7.
     112* Features will be added to development master, to be released as Django 1.8.
    113113
    114 * Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
    115   released as 1.6.1, 1.6.2, etc.
     114* Critical bug fixes will be applied to the ``stable/1.7.x`` branch, and
     115  released as 1.7.1, 1.7.2, etc.
    116116
    117117* Security fixes and bug fixes for data loss issues will be applied to
    118   ``master`` and to the ``stable/1.6.x``, ``stable/1.5.x``, and
    119   ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.6.1``,
    120   ``1.5.1``, ``1.4.1``, etc.
     118  ``master`` and to the ``stable/1.7.x``, ``stable/1.6.x``, and
     119  ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.7.1``,
     120  ``1.6.1``, ``1.4.1``, etc.
    121121
    122122* Documentation fixes will be applied to master, and, if easily backported, to
    123   the ``1.6.x`` branch.
     123  the ``1.7.x`` and ``1.6.x`` branches.
    124124
    125125.. _lts-releases:
    126126
    … … The follow releases have been designated for long-term support:  
    141141Release process
    142142===============
    143143
    144 Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.)
     144Django uses a time-based release schedule, with major (i.e. 1.8, 1.9, 2.0 etc.)
    145145releases every nine months, or more, depending on features.
    146146
    147147After each release, and after a suitable cooling-off period of a few weeks,
    … … in the ``A.B+1`` cycle.  
    211211Bug-fix releases
    212212----------------
    213213
    214 After a major release (e.g. 1.6), the previous release will go into bugfix
     214After a major release (e.g. A.B), the previous release will go into bugfix
    215215mode.
    216216
    217 The branch for the previous major release (e.g. ``stable/1.5.x``) will include
     217The branch for the previous major release (e.g. ``stable/A.B-1.x``) will include
    218218bugfixes. Critical bugs fixed on master must *also* be fixed on the bugfix
    219219branch; this means that commits need to cleanly separate bug fixes from feature
    220220additions. The developer who commits a fix to master will be responsible for
Back to Top