p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Updated release process for 2.0+ release numbering and latest practices.

This commit is contained in:
Mariusz Felisiak 2023-04-04 07:27:34 +02:00 committed by GitHub
parent 1d1ddffc27
commit 073b5fd400
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 50 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
docs/internals/howto-release-django.txt
View File

@ -15,12 +15,12 @@ There are three types of releases that you might need to make:
* Security releases: disclosing and fixing a vulnerability. This'll * Security releases: disclosing and fixing a vulnerability. This'll
generally involve two or three simultaneous releases -- e.g. generally involve two or three simultaneous releases -- e.g.
1.5.x, 1.6.x, and, depending on timing, perhaps a 1.7 alpha/beta/rc. 3.2.x, 4.0.x, and, depending on timing, perhaps a 4.1.x.
* Regular version releases: either a final release (e.g. 1.5) or a * Regular version releases: either a final release (e.g. 4.1) or a
bugfix update (e.g. 1.5.1). bugfix update (e.g. 4.1.1).
* Pre-releases: e.g. 1.6 alpha, beta, or rc. * Pre-releases: e.g. 4.2 alpha, beta, or rc.
The short version of the steps involved is: The short version of the steps involved is:
@ -139,12 +139,12 @@ any time leading up to the actual release:
and then commit the changed man page. and then commit the changed man page.
#. If this is the alpha release of a new series, create a new stable branch #. If this is the alpha release of a new series, create a new stable branch
from main. For example, when releasing Django 3.1: from main. For example, when releasing Django 4.2:
.. code-block:: shell .. code-block:: shell
$ git checkout -b stable/3.1.x origin/main $ git checkout -b stable/4.2.x origin/main
$ git push origin -u stable/3.1.x:stable/3.1.x $ git push origin -u stable/4.2.x:stable/4.2.x
At the same time, update the ``django_next_version`` variable in At the same time, update the ``django_next_version`` variable in
``docs/conf.py`` on the stable release branch to point to the new ``docs/conf.py`` on the stable release branch to point to the new
@ -154,12 +154,12 @@ any time leading up to the actual release:
#. If this is the "dot zero" release of a new series, create a new branch from #. If this is the "dot zero" release of a new series, create a new branch from
the current stable branch in the `django-docs-translations the current stable branch in the `django-docs-translations
<https://github.com/django/django-docs-translations>`_ repository. For <https://github.com/django/django-docs-translations>`_ repository. For
example, when releasing Django 2.2: example, when releasing Django 4.2:
.. code-block:: shell .. code-block:: shell
$ git checkout -b stable/2.2.x origin/stable/2.1.x $ git checkout -b stable/4.2.x origin/stable/4.1.x
$ git push origin stable/2.2.x:stable/2.2.x $ git push origin stable/4.2.x:stable/4.2.x
Preparing for release Preparing for release
===================== =====================
@ -188,7 +188,7 @@ OK, this is the fun part, where we actually push out a release!
.. code-block:: shell .. code-block:: shell
$ git checkout stable/1.5.x $ git checkout stable/4.1.x
$ git pull $ git pull
#. If this is a security release, merge the appropriate patches from #. If this is a security release, merge the appropriate patches from
@ -198,25 +198,25 @@ OK, this is the fun part, where we actually push out a release!
.. code-block:: shell .. code-block:: shell
$ git checkout stable/1.5.x $ git checkout stable/4.1.x
$ git merge --ff-only security/1.5.x $ git merge --ff-only security/4.1.x
(This assumes ``security/1.5.x`` is a branch in the ``django-security`` repo (This assumes ``security/4.1.x`` is a branch in the ``django-security`` repo
containing the necessary security patches for the next release in the 1.5 containing the necessary security patches for the next release in the 4.1
series.) series.)
If git refuses to merge with ``--ff-only``, switch to the security-patch If git refuses to merge with ``--ff-only``, switch to the security-patch
branch and rebase it on the branch you are about to merge it into (``git branch and rebase it on the branch you are about to merge it into (``git
checkout security/1.5.x; git rebase stable/1.5.x``) and then switch back and checkout security/4.1.x; git rebase stable/4.1.x``) and then switch back and
do the merge. Make sure the commit message for each security fix explains do the merge. Make sure the commit message for each security fix explains
that the commit is a security fix and that an announcement will follow that the commit is a security fix and that an announcement will follow
(:commit:`example security commit <bf39978a53f117ca02e9a0c78b76664a41a54745>`). (:commit:`example security commit <bf39978a53f117ca02e9a0c78b76664a41a54745>`).
#. For a feature release, remove the ``UNDER DEVELOPMENT`` header at the #. For a feature release, remove the ``UNDER DEVELOPMENT`` header at the
top of the release notes and add the release date on the next line. For a top of the release notes and add the release date on the next line. For a
patch release, replace ``*Under Development*`` with the release date. Make patch release, remove the ``Expected`` prefix and update the release date,
this change on all branches where the release notes for a particular version if necessary. Make this change on all branches where the release notes for a
are located. particular version are located.
#. Update the version number in ``django/__init__.py`` for the release. #. Update the version number in ``django/__init__.py`` for the release.
Please see `notes on setting the VERSION tuple`_ below for details Please see `notes on setting the VERSION tuple`_ below for details
@ -230,7 +230,7 @@ OK, this is the fun part, where we actually push out a release!
.. code-block:: shell .. code-block:: shell
$ git tag --sign --message="Tag 1.5.1" 1.5.1 $ git tag --sign --message="Tag 4.1.1" 4.1.1
You can check your work by running ``git tag --verify <tag>``. You can check your work by running ``git tag --verify <tag>``.
@ -282,26 +282,26 @@ OK, this is the fun part, where we actually push out a release!
checksumming applications to generate the checksums of the Django checksumming applications to generate the checksums of the Django
package and compare them to the checksums listed below. package and compare them to the checksums listed below.
Release packages: Release packages
================= ================
https://www.djangoproject.com/m/releases/<<RELEASE TAR.GZ FILENAME>> https://www.djangoproject.com/m/releases/<<MAJOR VERSION>>/<<RELEASE TAR.GZ FILENAME>>
https://www.djangoproject.com/m/releases/<<RELEASE WHL FILENAME>> https://www.djangoproject.com/m/releases/<<MAJOR VERSION>>/<<RELEASE WHL FILENAME>>
MD5 checksums: MD5 checksums
============== =============
<<MD5SUM>> <<RELEASE TAR.GZ FILENAME>> <<MD5SUM>> <<RELEASE TAR.GZ FILENAME>>
<<MD5SUM>> <<RELEASE WHL FILENAME>> <<MD5SUM>> <<RELEASE WHL FILENAME>>
SHA1 checksums: SHA1 checksums
=============== ==============
<<SHA1SUM>> <<RELEASE TAR.GZ FILENAME>> <<SHA1SUM>> <<RELEASE TAR.GZ FILENAME>>
<<SHA1SUM>> <<RELEASE WHL FILENAME>> <<SHA1SUM>> <<RELEASE WHL FILENAME>>
SHA256 checksums: SHA256 checksums
================= ================
<<SHA256SUM>> <<RELEASE TAR.GZ FILENAME>> <<SHA256SUM>> <<RELEASE TAR.GZ FILENAME>>
<<SHA256SUM>> <<RELEASE WHL FILENAME>> <<SHA256SUM>> <<RELEASE WHL FILENAME>>
@ -319,7 +319,7 @@ Making the release(s) available to the public
Now you're ready to actually put the release out there. To do this: Now you're ready to actually put the release out there. To do this:
#. Upload the release package(s) to the djangoproject server, replacing #. Upload the release package(s) to the djangoproject server, replacing
A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release: A.B. with the appropriate version number, e.g. 4.1 for a 4.1.x release:
.. code-block:: shell .. code-block:: shell
@ -339,7 +339,7 @@ Now you're ready to actually put the release out there. To do this:
.. code-block:: shell .. code-block:: shell
$ RELEASE_VERSION='1.7.2' $ RELEASE_VERSION='4.1.1'
$ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3` $ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`
$ python -m venv django-pip $ python -m venv django-pip
@ -354,12 +354,11 @@ Now you're ready to actually put the release out there. To do this:
This just tests that the tarballs are available (i.e. redirects are up) and This just tests that the tarballs are available (i.e. redirects are up) and
that they install correctly, but it'll catch silly mistakes. that they install correctly, but it'll catch silly mistakes.
#. Ask a few people on IRC to verify the checksums by visiting the checksums #. Run the `confirm-release`__ build on Jenkins to verify the checksum file(s)
file (e.g. https://media.djangoproject.com/pgp/Django-1.5b1.checksum.txt) (e.g. use ``4.2rc1`` for
and following the instructions in it. For bonus points, they can also unpack https://media.djangoproject.com/pgp/Django-4.2rc1.checksum.txt).
the downloaded release tarball and verify that its contents appear to be
correct (proper version numbers, no stray ``.pyc`` or other undesirable __ https://djangoci.com/job/confirm-release/
files).
#. Upload the release packages to PyPI (for pre-releases, only upload the wheel #. Upload the release packages to PyPI (for pre-releases, only upload the wheel
file): file):
@ -370,19 +369,19 @@ Now you're ready to actually put the release out there. To do this:
#. Go to the `Add release page in the admin`__, enter the new release number #. Go to the `Add release page in the admin`__, enter the new release number
exactly as it appears in the name of the tarball exactly as it appears in the name of the tarball
(``Django-<version>.tar.gz``). So for example enter "1.5.1" or "1.4c2", etc. (``Django-<version>.tar.gz``). So for example enter "4.1.1" or "4.2rc1",
If the release is part of an LTS branch, mark it so. etc. If the release is part of an LTS branch, mark it so.
__ https://www.djangoproject.com/admin/releases/release/add/ __ https://www.djangoproject.com/admin/releases/release/add/
If this is the alpha release of a new series, also create a Release object If this is the alpha release of a new series, also create a Release object
for the *final* release, ensuring that the *Release date* field is blank, for the *final* release, ensuring that the *Release date* field is blank,
thus marking it as *unreleased*. For example, when creating the Release thus marking it as *unreleased*. For example, when creating the Release
object for ``3.1a1``, also create ``3.1`` with the Release date field blank. object for ``4.2a1``, also create ``4.2`` with the Release date field blank.
#. Make the blog post announcing the release live. #. Make the blog post announcing the release live.
#. For a new version release (e.g. 1.5, 1.6), update the default stable version #. For a new version release (e.g. 4.1, 4.2), update the default stable version
of the docs by flipping the ``is_default`` flag to ``True`` on the of the docs by flipping the ``is_default`` flag to ``True`` on the
appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com`` appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com``
database (this will automatically flip it to ``False`` for all database (this will automatically flip it to ``False`` for all
@ -392,11 +391,11 @@ Now you're ready to actually put the release out there. To do this:
for the previous release. Update djangoproject.com's `robots.docs.txt`__ for the previous release. Update djangoproject.com's `robots.docs.txt`__
file by copying entries from ``manage_translations.py robots_txt`` from the file by copying entries from ``manage_translations.py robots_txt`` from the
current stable branch in the ``django-docs-translations`` repository. For current stable branch in the ``django-docs-translations`` repository. For
example, when releasing Django 2.2: example, when releasing Django 4.2:
.. code-block:: shell .. code-block:: shell
$ git checkout stable/2.2.x $ git checkout stable/4.2.x
$ git pull $ git pull
$ python manage_translations.py robots_txt $ python manage_translations.py robots_txt
@ -422,8 +421,8 @@ You're almost done! All that's left to do now is:
#. Update the ``VERSION`` tuple in ``django/__init__.py`` again, #. Update the ``VERSION`` tuple in ``django/__init__.py`` again,
incrementing to whatever the next expected release will be. For incrementing to whatever the next expected release will be. For
example, after releasing 1.5.1, update ``VERSION`` to example, after releasing 4.1.1, update ``VERSION`` to
``VERSION = (1, 5, 2, 'alpha', 0)``. ``VERSION = (4, 1, 2, 'alpha', 0)``.
#. Add the release in `Trac's versions list`_ if necessary (and make it the #. Add the release in `Trac's versions list`_ if necessary (and make it the
default by changing the ``default_version`` setting in the default by changing the ``default_version`` setting in the
@ -458,7 +457,7 @@ need to be done by the releaser.
``django.contrib.auth.hashers.PBKDF2PasswordHasher`` by about 20% ``django.contrib.auth.hashers.PBKDF2PasswordHasher`` by about 20%
(pick a round number). Run the tests, and update the 3 failing (pick a round number). Run the tests, and update the 3 failing
hasher tests with the new values. Make sure this gets noted in the hasher tests with the new values. Make sure this gets noted in the
release notes (see the 1.8 release notes for an example). release notes (see the 4.1 release notes for an example).
#. Remove features that have reached the end of their deprecation cycle. Each #. Remove features that have reached the end of their deprecation cycle. Each
removal should be done in a separate commit for clarity. In the commit removal should be done in a separate commit for clarity. In the commit
@ -467,7 +466,7 @@ need to be done by the releaser.
#. Remove ``.. versionadded::``, ``.. versionadded::``, and ``.. deprecated::`` #. Remove ``.. versionadded::``, ``.. versionadded::``, and ``.. deprecated::``
annotations in the documentation from two releases ago. For example, in annotations in the documentation from two releases ago. For example, in
Django 1.9, notes for 1.7 will be removed. Django 4.2, notes for 4.0 will be removed.
#. Add the new branch to `Read the Docs #. Add the new branch to `Read the Docs
<https://readthedocs.org/projects/django/>`_. Since the automatically <https://readthedocs.org/projects/django/>`_. Since the automatically
@ -500,8 +499,8 @@ be reported as "pre-alpha".
Some examples: Some examples:
* ``(1, 2, 1, 'final', 0)`` → "1.2.1" * ``(4, 1, 1, "final", 0)`` → "4.1.1"
* ``(1, 3, 0, 'alpha', 0)`` → "1.3 pre-alpha" * ``(4, 2, 0, "alpha", 0)`` → "4.2 pre-alpha"
* ``(1, 3, 0, 'beta', 2)`` → "1.3 beta 2" * ``(4, 2, 0, "beta", 1)`` → "4.2 beta 1"