Ticket #11493: deprecation.diff

File deprecation.diff, 5.8 KB (added by Alex Gaynor, 15 years ago)

  • docs/index.txt 

    diff --git a/docs/index.txt b/docs/index.txt
index 89ee463..8610537 100644
    a b The Django open-source project  
    200200
    201201    * **Django over time:**
    202202      :ref:`API stability <misc-api-stability>` |
    203       :ref:`Archive of release notes <releases-index>` | `Backwards-incompatible changes`_
     203      :ref:`Archive of release notes <releases-index>` | `Backwards-incompatible changes`_ |
     204      :ref:`Deprecation Timeline <internals-deprecation>`
    204205
    205206.. _Backwards-incompatible changes: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

  • new file docs/internals/deprecation.txt 

    diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
new file mode 100644
index 0000000..98e7d63
    - +  
     1.. _internals-deprecation:
     2
     3===========================
     4Django Deprecation Timeline
     5===========================
     6
     7This document outlines when various pieces of Django will be removed, following
     8their deprecation, as per the :ref:`Django deprecation policy
     9<internal-release-deprecation-policy>`
     10
     11    * 1.3
     12        * ``AdminSite.root()``.  This release will remove the old method for
     13          hooking up admin URLs.  This has been deprecated since the 1.1
     14          release.

  • docs/internals/index.txt 

    diff --git a/docs/internals/index.txt b/docs/internals/index.txt
index 0d54948..1cbbb87 100644
    a b the hood".  
    1717
    1818.. toctree::
    1919   :maxdepth: 1
    20    
     20
    2121   contributing
    2222   documentation
    2323   committers
    2424   release-process
     25   deprecation

  • docs/internals/release-process.txt 

    diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index 911b67e..6d4ad9e 100644
    a b Minor releases  
    4848--------------
    4949
    5050Minor release (1.1, 1.2, etc.) will happen roughly every six months -- see
    51 `release process`_, below for details.
     51`release process`_, below for details.
     52
     53.. _internal-release-deprecation-policy:
    5254
    5355These releases will contain new features, improvements to existing features, and
    5456such. A minor release may deprecate certain features from previous releases. If a
    5557feature in version ``A.B`` is deprecated, it will continue to work in version
    5658``A.B+1``. In version ``A.B+2``, use of the feature will raise a
    5759``PendingDeprecationWarning`` but will continue to work. Version ``A.B+3`` will
    58 remove the feature entirely. 
     60remove the feature entirely.
    5961
    6062So, for example, if we decided to remove a function that existed in Django 1.0:
    6163
    … … So, for example, if we decided to remove a function that existed in Django 1.0:  
    6668    * Django 1.2 will contain the backwards-compatible replica, but the warning
    6769      will be promoted to a full-fledged ``DeprecationWarning``. This warning is
    6870      *loud* by default, and will likely be quite annoying.
    69      
     71
    7072    * Django 1.3 will remove the feature outright.
    71    
     73
    7274Micro releases
    7375--------------
    7476
    … … varying levels:  
    9294
    9395    * The current development trunk will get new features and bug fixes
    9496      requiring major refactoring.
    95    
     97
    9698    * All bug fixes applied to the trunk will also be applied to the last
    9799      minor release, to be released as the next micro release.
    98      
     100
    99101    * Security fixes will be applied to the current trunk and the previous two
    100102      minor releases.
    101      
     103
    102104As a concrete example, consider a moment in time halfway between the release of
    103105Django 1.3 and 1.4. At this point in time:
    104106
    105107    * Features will be added to development trunk, to be released as Django 1.4.
    106    
     108
    107109    * Bug fixes will be applied to a ``1.3.X`` branch, and released as 1.3.1,
    108110      1.3.2, etc.
    109      
     111
    110112    * Security releases will be applied to trunk, a ``1.3.X`` branch and a
    111113      ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``,
    112114      ``1.2.1``, etc.
    … … Release process  
    117119===============
    118120
    119121Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
    120 releases every six months, or more, depending on features. 
     122releases every six months, or more, depending on features.
    121123
    122124After each previous release (and after a suitable cooling-off period of a week
    123125or two), the core development team will examine the landscape and announce a
    … … and an rc complete with string freeze two weeks before the end of the schedule.  
    174176Bug-fix releases
    175177----------------
    176178
    177 After a minor release (i.e 1.1), the previous release will go into bug-fix mode. 
     179After a minor release (i.e 1.1), the previous release will go into bug-fix mode.
    178180
    179181A branch will be created of the form ``branches/releases/1.0.X`` to track
    180182bug-fixes to the previous release. When possible, bugs fixed on trunk must
    181183*also* be fixed on the bug-fix branch; this means that commits need to cleanly
    182 separate bug fixes from feature additions. The developer who commits a fix to 
     184separate bug fixes from feature additions. The developer who commits a fix to
    183185trunk will be responsible for also applying the fix to the current bug-fix
    184186branch.  Each bug-fix branch will have a maintainer who will work with the
    185187committers to keep them honest on backporting bug fixes.
    … … development will be happening in a bunch of places:  
    193195
    194196    * On trunk, development towards 1.2 proceeds with small additions, bugs
    195197      fixes, etc. being checked in daily.
    196      
     198
    197199    * On the branch "branches/releases/1.1.X", bug fixes found in the 1.1
    198200      release are checked in as needed. At some point, this branch will be
    199201      released as "1.1.1", "1.1.2", etc.
    200202
    201203    * On the branch "branches/releases/1.0.X", security fixes are made if
    202204      needed and released as "1.0.2", "1.0.3", etc.
    203    
     205
    204206    * On feature branches, development of major features is done. These
    205207      branches will be merged into trunk before the end of phase two.
    206 
Back to Top