Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

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

  • Loading branch information...
commit dd6ef3197a4d10696c5ef4ddb55b0d4baaba4340 1 parent 037f81f
@timgraham timgraham authored
View
2  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
View
3  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
View
66 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
--------------------------
Please sign in to comment.
Something went wrong with that request. Please try again.