diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 4efeab9fc5..183519b514 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -219,7 +219,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 diff --git a/docs/internals/git.txt b/docs/internals/git.txt index e1d70be372..07837bac47 100644 --- a/docs/internals/git.txt +++ b/docs/internals/git.txt @@ -85,8 +85,7 @@ Other branches ============== Django uses branches to prepare for releases of Django (whether they be -:term:`major `, :term:`minor `, or -:term:`micro `). +:term:`major ` or :term:`minor `). 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 diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index 43d23717fc..69d4311592 100644 --- a/docs/internals/release-process.txt +++ b/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. +* ``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. -* ``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 +* ``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 `. .. 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 `. * 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 `. * 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 --------------------------