Fixed #23015 -- Fixed major/minor release terminology in docs.

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

@@ -221,7 +221,7 @@ Finally, there are a couple of updates to Django's documentation to make:
    under the ``A.B+2`` version describing what code will be removed.
 
 Once you have completed these steps, you are finished with the deprecation.
-In each minor release, all ``RemovedInDjangoXXWarning``\s matching the new
+In each major release, all ``RemovedInDjangoXXWarning``\s matching the new
 version are removed.
 
 Javascript patches

docs/internals/git.txt

@@ -85,8 +85,7 @@ Other branches
 ==============
 
 Django uses branches to prepare for releases of Django (whether they be
-:term:`major <Major release>`, :term:`minor <Minor release>`, or
-:term:`micro <Micro release>`).
+:term:`major <Major release>` or :term:`minor <Minor release>`).
 
 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/release-process.txt

@@ -11,23 +11,19 @@ Since version 1.0, Django's release numbering works as follows:
 
 * Versions are numbered in the form ``A.B`` or ``A.B.C``.
 
-* ``A`` is the *major version* number, which is only incremented for major
-  changes to Django, and these changes are not necessarily
-  backwards-compatible. That is, code you wrote for Django 1.6 may break
-  when we release Django 2.0.
-
-* ``B`` is the *minor version* number, which is incremented for large yet
-  backwards compatible changes.  Code written for Django 1.6 will continue
-  to work under Django 1.7. Exceptions to this rule will be listed in the
-  release notes.
-
-* ``C`` is the *micro version* number, which is incremented for bug and
-  security fixes. A new micro-release will be 100% backwards-compatible with
-  the previous micro-release. The only exception is when a security issue
+* ``A.B`` is the *major version* number. Each version will be mostly backwards
+  compatible with the previous release. Exceptions to this rule will be listed
+  in the release notes. When ``B == 9``, the next major release will be
+  ``A+1.0``. For example, Django 2.0 will follow Django 1.9. There won't be
+  anything special about "dot zero" releases.
+
+* ``C`` is the *minor version* number, which is incremented for bug and
+  security fixes. A new minor release will be 100% backwards-compatible with
+  the previous minor release. The only exception is when a security issue
   can't be fixed without breaking backwards-compatibility. If this happens,
   the release notes will provide detailed upgrade instructions.
 
-* Before a new minor release, we'll make alpha, beta, and release candidate
+* Before a new major release, we'll make alpha, beta, and release candidate
   releases. These are of the form ``A.B alpha/beta/rc N``, which means the
   ``Nth`` alpha/beta/release candidate of version ``A.B``.
 
@@ -42,17 +38,13 @@ security purposes, please see :doc:`our security policies <security>`.
 .. glossary::
 
   Major release
-    Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years",
-    not "months"), and may represent major, sweeping changes to Django.
-
-  Minor release
-    Minor release (1.5, 1.6, etc.) will happen roughly every nine months -- see
+    Major releases (1.5, 1.6, etc.) will happen roughly every nine months -- see
     `release process`_, below for details. These releases will contain new
     features, improvements to existing features, and such.
 
     .. _internal-release-deprecation-policy:
 
-    A minor release may deprecate certain features from previous releases. If a
+    A major release may deprecate certain features from previous releases. If a
     feature is deprecated in version ``A.B``, it will continue to work in versions
     ``A.B`` and  ``A.B+1`` but raise warnings. It will be removed in version
     ``A.B+2``.
@@ -70,13 +62,13 @@ security purposes, please see :doc:`our security policies <security>`.
 
     * Django 1.9 will remove the feature outright.
 
-  Micro release
-    Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
+  Minor release
+    Minor releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
     fix security issues.
 
-    These releases will be 100% compatible with the associated minor release, unless
-    this is impossible for security reasons. So the answer to "should I upgrade to
-    the latest micro release?" will always be "yes."
+    These releases will be 100% compatible with the associated major release,
+    unless this is impossible for security reasons. So the answer to "should I
+    upgrade to the latest minor release?" will always be "yes."
 
 .. _backwards-compatibility-policy:
 
@@ -89,8 +81,8 @@ varying levels:
 * The current development master will get new features and bug fixes
   requiring major refactoring.
 
-* Patches applied to the master branch must also be applied to the last minor
-  release, to be released as the next micro release, when they fix critical
+* Patches applied to the master branch must also be applied to the last major
+  release, to be released as the next minor release, when they fix critical
   problems:
 
   * Security issues.
@@ -101,12 +93,12 @@ varying levels:
 
   * Major functionality bugs in newly-introduced features.
 
-  The rule of thumb is that fixes will be backported to the last minor release
+  The rule of thumb is that fixes will be backported to the last major release
   for bugs that would have prevented a release in the first place (release
   blockers).
 
-* Security fixes will be applied to the current master and the previous two
-  minor releases.
+* Security fixes will be applied to the current master, the previous two major
+  releases, and the current :ref:`LTS release <lts-releases>`.
 
 * Committers may choose to backport bugfixes at their own discretion,
   provided they do not introduce backwards incompatibilities.
@@ -150,7 +142,7 @@ The follow releases have been designated for long-term support:
 Release process
 ===============
 
-Django uses a time-based release schedule, with minor (i.e. 1.6, 1.7, etc.)
+Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.)
 releases every nine months, or more, depending on features.
 
 After each release, and after a suitable cooling-off period of a few weeks, the
@@ -220,14 +212,14 @@ in the ``A.B+1`` cycle.
 Bug-fix releases
 ----------------
 
-After a minor release (e.g. 1.6), the previous release will go into bugfix
+After a major release (e.g. 1.6), the previous release will go into bugfix
 mode.
 
-A branch will be created of the form ``stable/1.5.x`` to track bugfixes to the
-previous release. 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 additions. The developer who commits a fix to master will be
-responsible for also applying the fix to the current bugfix branch.
+The branch for the previous major release (e.g. ``stable/1.5.x``) will include
+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
+additions. The developer who commits a fix to master will be responsible for
+also applying the fix to the current bugfix branch.
 
 How this all fits together
 --------------------------