Clarified policy for stable branches.
Thanks Ramiro Morales for the initial patch and Preston Holmes for the review.
This commit is contained in:
Tim Graham
parent
2699219c23
commit
01948e384f
|
|
@ -35,8 +35,9 @@ The Git repository includes several `branches`_:
|
|||
the next packaged release of Django. This is where most development
|
||||
activity is focused.
|
||||
|
||||
* ``stable/A.B.x`` are the maintenance branches. They are used to support
|
||||
older versions of Django.
|
||||
* ``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.
|
||||
|
||||
* ``soc20XX/<project>`` branches were used by students who worked on Django
|
||||
during the 2009 and 2010 Google Summer of Code programs.
|
||||
|
|
@ -83,13 +84,50 @@ coding style and how to generate and submit a patch.
|
|||
Other branches
|
||||
==============
|
||||
|
||||
Django uses branches for two main purposes:
|
||||
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>`).
|
||||
|
||||
1. Development of major or experimental features, to keep them from
|
||||
affecting progress on other work in master.
|
||||
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
|
||||
done on contributor's forks, but the Subversion feature branches remain in Git
|
||||
for historical reference.
|
||||
|
||||
2. Security and bugfix support for older releases of Django, during
|
||||
their support lifetimes.
|
||||
Stable branches
|
||||
---------------
|
||||
|
||||
These branches can be found in the repository as ``stable/A.B.x``
|
||||
branches and will be created right after the first alpha is tagged.
|
||||
|
||||
For example, immediately after *Django 1.5 alpha 1* was tagged, the branch
|
||||
``stable/1.5.x`` was created and all further work on preparing the code for the
|
||||
final 1.5 release was done there.
|
||||
|
||||
These branches also provide limited bugfix support for the most recent released
|
||||
version of Django and security support for the two most recently-released
|
||||
versions of Django.
|
||||
|
||||
For example, after the release of Django 1.5, the branch ``stable/1.5.x``
|
||||
receives only fixes for security and critical stability bugs, which are
|
||||
eventually released as Django 1.5.1 and so on, ``stable/1.4.x`` receives only
|
||||
security fixes, and ``stable/1.3.x`` no longer receives any updates.
|
||||
|
||||
.. admonition:: Historical information
|
||||
|
||||
This policy for handling ``stable/A.B.x`` branches was adopted starting
|
||||
with the Django 1.5 release cycle.
|
||||
|
||||
Previously, these branches weren't created until right after the releases
|
||||
and the stabilization work occurred on the main repository branch. Thus,
|
||||
no new features development work for the next release of Django could be
|
||||
committed until the final release happened.
|
||||
|
||||
For example, shortly after the release of Django 1.3 the branch
|
||||
``stable/1.3.x`` was created. Official support for that release has expired,
|
||||
and so it no longer receives direct maintenance from the Django project.
|
||||
However, that and all other similarly named branches continue to exist and
|
||||
interested community members have occasionally used them to provide
|
||||
unofficial support for old Django releases.
|
||||
|
||||
Feature-development branches
|
||||
----------------------------
|
||||
|
|
@ -203,30 +241,6 @@ All of the above-mentioned branches now reside in ``attic``.
|
|||
Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature
|
||||
branches, used for Google Summer of Code projects.
|
||||
|
||||
Support and bugfix branches
|
||||
---------------------------
|
||||
|
||||
In addition to fixing bugs in current master, the Django project provides
|
||||
official bugfix support for the most recent released version of Django, and
|
||||
security support for the two most recently-released versions of Django.
|
||||
|
||||
This support is provided via branches in which the necessary bug or security
|
||||
fixes are applied; the branches are then used as the basis for issuing bugfix
|
||||
or security releases.
|
||||
|
||||
These branches can be found in the repository as ``stable/A.B.x``
|
||||
branches, and new branches will be created there after each new Django
|
||||
release.
|
||||
|
||||
For example, shortly after the release of Django 1.0, the branch
|
||||
``stable/1.0.x`` was created to receive bug fixes, and shortly after the
|
||||
release of Django 1.1 the branch ``stable/1.1.x`` was created.
|
||||
|
||||
Official support for the above mentioned releases has expired, and so they no
|
||||
longer receive direct maintenance from the Django project. However, the
|
||||
branches continue to exist and interested community members have occasionally
|
||||
used them to provide unofficial support for old Django releases.
|
||||
|
||||
Tags
|
||||
====
|
||||
|
||||
|
|
|
|||
|
|
@ -39,15 +39,13 @@ issued from those branches.
|
|||
For more information about how the Django project issues new releases for
|
||||
security purposes, please see :doc:`our security policies <security>`.
|
||||
|
||||
Major releases
|
||||
--------------
|
||||
.. 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 releases
|
||||
--------------
|
||||
|
||||
Minor release
|
||||
Minor release (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.
|
||||
|
|
@ -73,9 +71,7 @@ Django 1.5:
|
|||
|
||||
* Django 1.7 will remove the feature outright.
|
||||
|
||||
Micro releases
|
||||
--------------
|
||||
|
||||
Micro release
|
||||
Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
|
||||
fix security issues.
|
||||
|
||||
|
|
@ -126,15 +122,15 @@ Django 1.6 and 1.7. At this point in time:
|
|||
|
||||
* Features will be added to development master, to be released as Django 1.7.
|
||||
|
||||
* 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.
|
||||
|
||||
* Security fixes will be applied to ``master``, to the ``stable/1.6.X``
|
||||
branch, and to the ``stable/1.5.X`` branch. They will trigger the release of
|
||||
* Security fixes will be applied to ``master``, to the ``stable/1.6.x``
|
||||
branch, and to the ``stable/1.5.x`` branch. They will trigger the release of
|
||||
``1.6.1``, ``1.5.1``, etc.
|
||||
|
||||
* 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. Bugfixes may also be backported.
|
||||
|
||||
.. _release-process:
|
||||
|
||||
|
|
@ -193,9 +189,9 @@ Phase two will culminate with an alpha release. At this point, the
|
|||
Phase three: bugfixes
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The last third of a release is spent fixing bugs -- no new features will be
|
||||
accepted during this time. We'll try to release a beta release after one month
|
||||
and a release candidate after two months.
|
||||
The last third of a release cycle is spent fixing bugs -- no new features will
|
||||
be accepted during this time. We'll try to release a beta release after one
|
||||
month and a release candidate after two months.
|
||||
|
||||
The release candidate marks the string freeze, and it happens at least two
|
||||
weeks before the final release. After this point, new translatable strings
|
||||
|
|
|
|||
Loading…
Reference in New Issue