Updated release process for new release schedule.

docs/internals/contributing/localizing.txt

@@ -46,11 +46,11 @@ translating or add a language that isn't yet translated, here's what to do:
      `Transifex User Guide`_.
 
 Translations from Transifex are only integrated into the Django repository at
-the time of a new major release. We try to update them a second time during one
-of the following minor releases, but that depends on the translation manager's
-availability. So don't miss the string freeze period (between the release
-candidate and the major release) to take the opportunity to complete and fix
-the translations for your language!
+the time of a new :term:`feature release`. We try to update them a second time
+during one of the following :term:`patch release`\s, but that depends on the
+translation manager's availability. So don't miss the string freeze period
+(between the release candidate and the feature release) to take the opportunity
+to complete and fix the translations for your language!
 
 Formats
 -------

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -236,11 +236,11 @@ Finally, there are a couple of updates to Django's documentation to make:
    the "Features deprecated in A.B" heading.
 
 #) Add an entry in the deprecation timeline (``docs/internals/deprecation.txt``)
-   under the ``A.B+2`` version describing what code will be removed.
+   under the appropriate version describing what code will be removed.
 
 Once you have completed these steps, you are finished with the deprecation.
-In each major release, all ``RemovedInDjangoXXWarning``\s matching the new
-version are removed.
+In each :term:`feature release`, all ``RemovedInDjangoXXWarning``\s matching
+the new version are removed.
 
 JavaScript patches
 ------------------

docs/internals/contributing/writing-documentation.txt

@@ -192,7 +192,7 @@ __ http://sphinx-doc.org/markup/
 
   To link, use ``:djadminopt:`--traceback```.
 
-* Links to Trac tickets (typically reserved for minor release notes)::
+* Links to Trac tickets (typically reserved for patch release notes)::
 
         :ticket:`12345`
 

docs/internals/git.txt

@@ -36,8 +36,8 @@ The Git repository includes several `branches`_:
   activity is focused.
 
 * ``stable/A.B.x`` are the branches where release preparation work happens.
-  They are also used for support and bugfix releases which occur as necessary
-  after the initial release of a major or minor version.
+  They are also used for bugfix and security releases which occur as necessary
+  after the initial release of a feature version.
 
 * ``soc20XX/<project>`` branches were used by students who worked on Django
   during the 2009 and 2010 Google Summer of Code programs.
@@ -84,8 +84,7 @@ coding style and how to generate and submit a patch.
 Other branches
 ==============
 
-Django uses branches to prepare for releases of Django (whether they be
-:term:`major <Major release>` or :term:`minor <Minor release>`).
+Django uses branches to prepare for releases of Django.
 
 In the past when Django was hosted on Subversion, branches were also used for
 feature development. Now Django is hosted on Git and feature development is

docs/internals/howto-release-django.txt

@@ -112,7 +112,7 @@ any time leading up to the actual release:
 #. Double-check that the release notes index has a link to the notes
    for the new release; this will be in ``docs/releases/index.txt``.
 
-#. If this is a major release, ensure translations from Transifex have been
+#. If this is a feature release, ensure translations from Transifex have been
    integrated. This is typically done by a separate translation's manager
    rather than the releaser, but here are the steps. Provided you have an
    account on Transifex::
@@ -181,9 +181,9 @@ OK, this is the fun part, where we actually push out a release!
 
    __ https://github.com/django/django/commit/3ef4bbf495cc6c061789132e3d50a8231a89406b
 
-#. For a major version release, remove the ``UNDER DEVELOPMENT`` header at the
+#. For a feature release, remove the ``UNDER DEVELOPMENT`` header at the
    top of the release notes and add the release date on the next line. For a
-   minor release, replace ``*Under Development*`` with the release date. Make
+   patch release, replace ``*Under Development*`` with the release date. Make
    this change on all branches where the release notes for a particular version
    are located.
 
@@ -377,9 +377,9 @@ need to be done by the releaser.
    ``docs/fixtures/doc_releases.json`` JSON fixture, so people without access
    to the production DB can still run an up-to-date copy of the docs site.
 
-#. Create a stub release note for the new major version. Use the stub from the
-   previous major version or use the previous major version and delete most of
-   the contents leaving only section headings.
+#. Create a stub release note for the new feature version. Use the stub from
+   the previous feature release version or copy the contents from the previous
+   feature version and delete most of the contents leaving only the headings.
 
 #. Increase the default PBKDF2 iterations in
    ``django.contrib.auth.hashers.PBKDF2PasswordHasher`` by about 20%

docs/internals/organization.txt

@@ -166,7 +166,7 @@ The technical board is an elected group of five committers. They're expected
 to be experienced but there's no formal seniority requirement. Its current
 composition is published :ref:`here <technical-board-list>`.
 
-A new board is elected after each major release of Django. The election
+A new board is elected after each feature release of Django. The election
 process is managed by a returns officer nominated by the outgoing technical
 board. The election process works as follows:
 

docs/internals/security.txt

@@ -59,8 +59,8 @@ for several versions of Django:
   Django 1.3. Upon the release of Django 1.5, Django 1.3's security
   support will end.
 
-* :ref:`Long-term support (LTS) releases <lts-releases>` will receive
-  security updates for a specified period.
+* :term:`Long-term support release`\s will receive security updates for a
+  specified period.
 
 When new releases are issued for security reasons, the accompanying
 notice will include a list of affected versions. This list is

docs/misc/api-stability.txt

@@ -2,13 +2,12 @@
 API stability
 =============
 
-:doc:`The release of Django 1.0 </releases/1.0>` comes with a promise of API
-stability and forwards-compatibility. In a nutshell, this means that code you
-develop against a 1.X version of Django will continue to work with future
-1.X releases. You may need to make minor changes when upgrading the version of
-Django your project uses: see the "Backwards incompatible changes" section of
-the :doc:`release note </releases/index>` for the version or versions to which
-you are upgrading.
+Django promises API stability and forwards-compatibility since version 1.0. In
+a nutshell, this means that code you develop against a version of Django will
+continue to work with future releases. You may need to make minor changes when
+upgrading the version of Django your project uses: see the "Backwards
+incompatible changes" section of the :doc:`release note </releases/index>` for
+the version or versions to which you are upgrading.
 
 What "stable" means
 ===================
@@ -24,8 +23,8 @@ In this context, stable means:
 
 - If, for some reason, an API declared stable must be removed or replaced, it
   will be declared deprecated but will remain in the API for at least two
-  minor version releases. Warnings will be issued when the deprecated method
-  is called.
+  feature releases. Warnings will be issued when the deprecated method is
+  called.
 
   See :ref:`official-releases` for more details on how Django's version
   numbering scheme works, and how features will be deprecated.

docs/releases/1.8.txt

@@ -12,10 +12,10 @@ incompatible changes`_ you'll want to be aware of when upgrading from Django
 features`_, and some features have reached the end of their deprecation process
 and `have been removed`_.
 
-Django 1.8 has been designated as Django's second :ref:`"Long-Term Support"
-(LTS) <lts-releases>` release. It will receive security updates for at least
-three years after its release. Support for the previous LTS, Django 1.4, will
-end 6 months from the release date of Django 1.8.
+Django 1.8 has been designated as Django's second :term:`long-term support
+release`. It will receive security updates for at least three years after its
+release. Support for the previous LTS, Django 1.4, will end 6 months from the
+release date of Django 1.8.
 
 .. _`new features`: `What's new in Django 1.8`_
 .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.8`_

docs/releases/index.txt

@@ -15,7 +15,7 @@ version.
 Final releases
 ==============
 
-Below are release notes through Django |version| and its minor releases. Newer
+Below are release notes through Django |version| and its patch releases. Newer
 versions of the documentation contain the release notes for any later releases.
 
 .. _development_release_notes:

docs/topics/migrations.txt

@@ -376,9 +376,10 @@ similar to the following::
             'id': 'fields.W900',  # pick a unique ID for your field.
         }
 
-After a deprecation period of your choosing (two major releases for fields in
-Django itself), change the ``system_check_deprecated_details`` attribute to
-``system_check_removed_details`` and update the dictionary similar to::
+After a deprecation period of your choosing (two or three feature releases for
+fields in Django itself), change the ``system_check_deprecated_details``
+attribute to ``system_check_removed_details`` and update the dictionary similar
+to::
 
     class IPAddressField(Field):
         system_check_removed_details = {