mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-06-08 21:19:13 +00:00
Code Issues 32 Releases Wiki Activity

[5.1.x] Updated the release process documentation to reflect the current process.

Browse Source 
Backport of 0ba35a49481c9fec4731ca0dd2230d8d48f51389 from main.
This commit is contained in:
Sarah Boyce 2025-01-21 13:18:19 +01:00
parent 8ad0d09a00
commit 3c1f94d70f
1 changed files with 47 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
docs/internals/release-process.txt
View File

@ -184,54 +184,68 @@ Release process
Django uses a time-based release schedule, with feature releases every eight Django uses a time-based release schedule, with feature releases every eight
months or so. months or so.
After each feature release, the release manager will announce a timeline for After each feature release, the release manager will publish a timeline for the
the next feature release. next feature release. The timeline for an upcoming feature release can be found
in the corresponding wiki roadmap page, e.g.
https://code.djangoproject.com/wiki/Version6.0Roadmap.
Release cycle Feature release schedule and stages
------------- -----------------------------------
Each release cycle consists of three parts: Active development / Pre-feature freeze
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phase one: feature proposal Work begins on the feature release ``A.B`` after the feature freeze of the
~~~~~~~~~~~~~~~~~~~~~~~~~~~ previous release, i.e. when the ``stable/A.B-1.x`` branch is forked.
The first phase of the release process will include figuring out what major You can find the current branch under active development in the
features to include in the next version. This should include a good deal of `Django release process
preliminary work on those features -- working code trumps grand design. <https://code.djangoproject.com/#Djangoreleaseprocess>`_ on Trac.
Major features for an upcoming release will be added to the wiki roadmap page, Feature freeze / Alpha release
e.g. https://code.djangoproject.com/wiki/Version1.11Roadmap. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phase two: development All major and minor features, including deprecations and breaking changes, must
~~~~~~~~~~~~~~~~~~~~~~ be merged by the feature freeze. Any features not done by this point will be
deferred to the next feature release.
The second part of the release schedule is the "heads-down" working period. At this point, the ``stable/A.B.x`` branch will be forked from ``main``.
Using the roadmap produced at the end of phase one, we'll all work very hard to
get everything on it done.
At the end of phase two, any unfinished features will be postponed until the Non-release blocking bug fix freeze / Beta release
next release. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phase two will culminate with an alpha release. At this point, the After the alpha, all bug fixes merged in ``main`` are also backported to
``stable/A.B.x`` branch will be forked from ``main``. ``stable/A.B.x``. Refactors are backported at the discretion of the merger.
Mergers will be more and more conservative with backports, to avoid introducing
regressions.
Phase three: bugfixes In parallel to this phase, ``main`` can continue to receive new features, to be
~~~~~~~~~~~~~~~~~~~~~ released in the ``A.B+1`` cycle.
The last part of a release cycle is spent fixing bugs -- no new features will Translation string freeze / Release candidate release
be accepted during this time. We'll try to release a beta release one month ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
after the alpha and a release candidate one month after the beta.
If there is still a consistent stream of release blockers coming in at the
planned release candidate date, a beta 2 will be released to encourage further
testing and the release candidate date will be pushed out ~1 month.
The release candidate marks the string freeze, and it happens at least two The release candidate marks the string freeze, and it happens at least two
weeks before the final release. After this point, new translatable strings weeks before the final release. Translators can then submit updated
must not be added. translations for inclusion in the final release. After this point, new
translatable strings must not be added.
During this phase, mergers will be more and more conservative with backports, After the release candidate, only release blockers and documentation fixes are
to avoid introducing regressions. After the release candidate, only release backported.
blockers and documentation fixes should be backported.
In parallel to this phase, ``main`` can receive new features, to be released Final release
in the ``A.B+1`` cycle. ~~~~~~~~~~~~~
Ideally, the final release will ship two weeks after the last release
candidate.
If there are major bugs still being found 2 weeks after the release candidate,
there will be a decision on how to proceed (likely another release candidate
would be issued and the final release date will be pushed out).
Bug-fix releases Bug-fix releases
---------------- ----------------