Ticket #23079: 23079.diff

File 23079.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 69d4311..7b6ea0a 100644
    a b security purposes, please see :doc:`our security policies <security>`.  
    6767    fix security issues.
    6868
    6969    These releases will be 100% compatible with the associated major release,
    70     unless this is impossible for security reasons. So the answer to "should I
    71     upgrade to the latest minor release?" will always be "yes."
     70    unless this is impossible for security reasons or to prevent data loss.
     71    So the answer to "should I upgrade to the latest minor release?" will always
     72    be "yes."
    7273
    7374.. _backwards-compatibility-policy:
    7475
    … … varying levels:  
    8788
    8889  * Security issues.
    8990
    90   * Data-loss bugs.
     91  * Data loss bugs.
    9192
    9293  * Crashing bugs.
    9394
    … … varying levels:  
    9798  for bugs that would have prevented a release in the first place (release
    9899  blockers).
    99100
    100 * Security fixes will be applied to the current master, the previous two major
    101   releases, and the current :ref:`LTS release <lts-releases>`.
    102 
    103 * Committers may choose to backport bugfixes at their own discretion,
    104   provided they do not introduce backwards incompatibilities.
     101* Security fixes and data loss bugs will be applied to the current master, the
     102  last two major releases, and the current :ref:`LTS release <lts-releases>`.
    105103
    106104* Documentation fixes generally will be more freely backported to the last
    107105  release branch. That's because it's highly advantageous to have the docs for
    … … Django 1.6 and 1.7. At this point in time:  
    116114* Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
    117115  released as 1.6.1, 1.6.2, etc.
    118116
    119 * Security fixes will be applied to ``master``, to the ``stable/1.6.x``
    120   branch, and to the ``stable/1.5.x`` branch. They will trigger the release of
    121   ``1.6.1``, ``1.5.1``, etc.
     117* 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.
    122121
    123122* Documentation fixes will be applied to master, and, if easily backported, to
    124   the ``1.6.x`` branch. Bugfixes may also be backported.
     123  the ``1.6.x`` branch.
    125124
    126125.. _lts-releases:
    127126
    … … bugfixes. Critical bugs fixed on master must *also* be fixed on the bugfix  
    220219branch; this means that commits need to cleanly separate bug fixes from feature
    221220additions. The developer who commits a fix to master will be responsible for
    222221also applying the fix to the current bugfix branch.
    223 
    224 How this all fits together
    225 --------------------------
    226 
    227 Let's look at a hypothetical example for how this all first together. Imagine,
    228 if you will, a point about halfway between 1.5 and 1.6. At this point,
    229 development will be happening in a bunch of places:
    230 
    231 * On master, development towards 1.6 proceeds with small additions, bugs
    232   fixes, etc. being checked in daily.
    233 
    234 * On the branch ``stable/1.5.x``, fixes for critical bugs found in
    235   the 1.5 release are checked in as needed. At some point, this branch will
    236   be released as "1.5.1", "1.5.2", etc.
    237 
    238 * On the branch ``stable/1.4.x``, security fixes are made if
    239   needed and released as "1.4.2", "1.4.3", etc.
    240 
    241 * Development of major features is done in branches in forks of the main
    242   repository. These branches will be merged into ``master`` before "1.6
    243   alpha 1".
Back to Top