mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-11-04 05:35:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

Fixed #23079 -- Added data loss issues to those that will be backported to LTS.

Browse source
This commit is contained in:
Tim Graham 2014-07-29 09:23:03 -04:00
parent b012122d30
commit e46801f13d
1 changed files with 17 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

56
docs/internals/release-process.txt
View file

@ -19,9 +19,9 @@ Since version 1.0, Django's release numbering works as follows:
* ``C`` is the *minor version* number, which is incremented for bug and * ``C`` is the *minor version* number, which is incremented for bug and
security fixes. A new minor release will be 100% backwards-compatible with security fixes. A new minor release will be 100% backwards-compatible with
the previous minor release. The only exception is when a security issue the previous minor release. The only exception is when a security or data loss
can't be fixed without breaking backwards-compatibility. If this happens, issue can't be fixed without breaking backwards-compatibility. If this
the release notes will provide detailed upgrade instructions. happens, the release notes will provide detailed upgrade instructions.
* Before a new major 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 releases. These are of the form ``A.B alpha/beta/rc N``, which means the
@ -67,8 +67,9 @@ security purposes, please see :doc:`our security policies <security>`.
fix security issues. fix security issues.
These releases will be 100% compatible with the associated major release, These releases will be 100% compatible with the associated major release,
unless this is impossible for security reasons. So the answer to "should I unless this is impossible for security reasons or to prevent data loss.
upgrade to the latest minor release?" will always be "yes." So the answer to "should I upgrade to the latest minor release?" will always
be "yes."
.. _backwards-compatibility-policy: .. _backwards-compatibility-policy:
@ -87,7 +88,7 @@ varying levels:
* Security issues. * Security issues.
* Data-loss bugs. * Data loss bugs.
* Crashing bugs. * Crashing bugs.
@ -97,11 +98,8 @@ varying levels:
for bugs that would have prevented a release in the first place (release for bugs that would have prevented a release in the first place (release
blockers). blockers).
* Security fixes will be applied to the current master, the previous two major * Security fixes and data loss bugs will be applied to the current master, the
releases, and the current :ref:`LTS release <lts-releases>`. last 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.
* Documentation fixes generally will be more freely backported to the last * Documentation fixes generally will be more freely backported to the last
release branch. That's because it's highly advantageous to have the docs for release branch. That's because it's highly advantageous to have the docs for
@ -116,12 +114,13 @@ Django 1.6 and 1.7. At this point in time:
* Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and * Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
released as 1.6.1, 1.6.2, etc. released as 1.6.1, 1.6.2, etc.
* Security fixes will be applied to ``master``, to the ``stable/1.6.x`` * Security fixes and bug fixes for data loss issues will be applied to
branch, and to the ``stable/1.5.x`` branch. They will trigger the release of ``master`` and to the ``stable/1.6.x``, ``stable/1.5.x``, and
``1.6.1``, ``1.5.1``, etc. ``stable/1.4.x`` (LTS) branches. They will trigger the release of ``1.6.1``,
``1.5.1``, ``1.4.1``, etc.
* Documentation fixes will be applied to master, and, if easily backported, to * Documentation fixes will be applied to master, and, if easily backported, to
the ``1.6.x`` branch. Bugfixes may also be backported. the ``1.6.x`` branch.
.. _lts-releases: .. _lts-releases:
@ -129,9 +128,9 @@ Long-term support (LTS) releases
================================ ================================
Additionally, the Django team will occasionally designate certain releases Additionally, the Django team will occasionally designate certain releases
to be "Long-term support" (LTS) releases. LTS releases will get security fixes to be "Long-term support" (LTS) releases. LTS releases will get security and
applied for a guaranteed period of time, typically 3+ years, regardless of data loss fixes applied for a guaranteed period of time, typically 3+ years,
the pace of releases afterwards. regardless of the pace of releases afterwards.
The follow releases have been designated for long-term support: The follow releases have been designated for long-term support:
@ -220,24 +219,3 @@ 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 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 additions. The developer who commits a fix to master will be responsible for
also applying the fix to the current bugfix branch. also applying the fix to the current bugfix branch.
How this all fits together
--------------------------
Let's look at a hypothetical example for how this all first together. Imagine,
if you will, a point about halfway between 1.5 and 1.6. At this point,
development will be happening in a bunch of places:
* On master, development towards 1.6 proceeds with small additions, bugs
fixes, etc. being checked in daily.
* On the branch ``stable/1.5.x``, fixes for critical bugs found in
the 1.5 release are checked in as needed. At some point, this branch will
be released as "1.5.1", "1.5.2", etc.
* On the branch ``stable/1.4.x``, security fixes are made if
needed and released as "1.4.2", "1.4.3", etc.
* Development of major features is done in branches in forks of the main
repository. These branches will be merged into ``master`` before "1.6
alpha 1".