How is Django Formed?¶

本文解释如何释放Django。

如果您进行更改，请保留这些说明！ 这里的要点是描述性的，而不是规范性的，所以可以自由地简化或以其他方式进行更改，但是 相应更新本文档！

Overview¶

您可能需要执行以下三种类型的发布：

安全版本：披露和修复漏洞。这通常涉及两个或三个同时释放。 1.5.x，1.6.x，根据时机，可能是1.7 alpha / beta / rc。
正版版本：最终版本（例如1.5）或修补程序更新（例如1.5.1）。
预发行版：例如1.6 alpha，beta或rc。

所涉及的步骤的简短版本是：

如果这是安全版本，请在实际发布前一周预先通知安全通讯组列表。
校对发行说明，寻找组织和写错误。起草博客文章和电子邮件公告。
更新版本号并创建发行包。
将软件包上传到djangoproject.com服务器。
将新版本上传到PyPI。
在djangoproject.com上的管理员中声明新版本。
发布博客条目并发送电子邮件公告。
更新版本号后发布。

有很多细节，所以请继续阅读。

Prerequisites¶

在开始之前你需要一些东西：

GPG密钥。如果您要使用的密钥不是您的默认签名密钥，则需要将-u you@example.com添加到每个GPG签名命令，其中you@example.com是与您要使用的密钥相关联的电子邮件地址。
安装一些必需的Python包：
```
$ pip install wheel twine
```
在PyPI上访问Django的记录。使用您的凭据创建文件：
〜/ .pypirc
```
[pypi]
username:YourUsername
password:YourPassword
```
访问djangoproject.com服务器以上传文件。
访问djangoproject.com上的管理员为“网站维护者”。
可以发布到django-announce。
如果这是安全发布，请访问预通知通讯组列表。

如果这是你的第一个版本，你需要与James和/或Jacob协调，以得到所有这些事情排队。

Pre-release tasks¶

甚至在开始发布过程之前，需要关注几个项目。这个东西在发布前一周开始；大多数可以做任何时间导致实际版本：

如果这是安全版本，请在发布之前发出一周的预通知。我们维护了在私人django-core存储库中获取这些预通知电子邮件的人员的列表。将邮件发送到security@djangoproject.com，并将预通知收件人BCC。该电子邮件应该由您将用于发布的密钥进行签名，并且应包括CVE ID（请求与供应商：djangoproject，产品：django）和修复每个问题的修补程序。另外，即将发布的安全版本的notify django-announce。
随着发布接近，请观察Trac以确保没有释放阻滞剂留给即将发布的版本。
请与其他提交者确认，以确保他们没有任何未提交的版本更改。
校对发行说明，包括查看在线版本以捕获任何断开的链接或reST错误，并确保发行说明包含正确的日期。
仔细检查发布说明中是否提到了已弃用的任何API的弃用时间表，并提及Python版本支持中的任何更改。
仔细检查发行说明索引是否有指向新版本说明的链接；这将在docs/releases/index.txt中。
如果这是功能版本，请确保已经整合了Transifex的翻译。这通常由单独的翻译经理而不是释放者完成，但这里是步骤。如果您在Transifex有一个帐户：
```
$ python scripts/manage_translations.py fetch
```
然后提交更改/添加的文件（.po和.mo）。有时候有验证错误需要被调试，所以在发布需要之前要避免这样做。

Update the django-admin manual page：

$ cd docs
$ make man
$ man _build/man/django-admin.1  # do a quick sanity check
$ cp _build/man/django-admin.1 man/django-admin.1

然后提交更改的手册页。

Preparing for release¶

写发布的公告博客文章。您可以随时将其输入到管理员，并将其标记为非活动。以下是几个示例：示例安全公告，示例常规发布公告，示例预发布公告。

Actually rolling the release¶

OK，这是有趣的部分，我们实际推出一个发布！

检查Jenkins是绿色的您正在推出的版本。你可能不应该发布一个版本，直到它是绿色。
发布始终从发布分支开始，因此您应该确保您处于稳定的分支并且是最新的。像这样：
```
$ git checkout stable/1.5.x
$ git pull
```
如果这是安全版本，请从django-private合并相应的修补程序。根据需要重新编写这些补丁，使每个补丁都是发布分支上的简单提交，而不是合并提交。要确保这一点，请将它们与--ff-only标志合并；例如：
```
$ git checkout stable/1.5.x
$ git merge --ff-only security/1.5.x
```
（这假设django-private是security/1.5.x库中的一个分支，包含1.5系列中下一个版本的必要安全补丁）。

如果git拒绝与--ff-only合并，请切换到安全补丁分支，然后将其分支到您要将其合并到的分支（git t3 > checkout security / 1.5.x； git rebase stable / 1.5.x ），然后切换回并执行合并。确保每个安全修补程序的提交消息都说明该提交是一个安全修复程序，并且随后会有通告（示例安全提交）。
对于功能版本，请删除发行说明顶部的UNDER DEVELOPMENT标题，并在下一行添加发布日期。对于补丁版本，请在发布日期替换* 开发*。在特定版本的发行说明所在的所有分支上进行此更改。
在版本的django/__init__.py中更新版本号。有关VERSION的详细信息，请参阅下面的有关设置VERSION元组的注释。
如果这是预发布包，请更新setup.py中的“开发状态”trove分类以反映这一点。否则，请确保分类器设置为 发展状态 :: 5 - 生产/稳定.
使用git 标记标记版本。像这样：
```
$ git tag --sign --message="Tag 1.5.1" 1.5.1
```
您可以运行git 标签 - 验证＆lt； tag＆gt； t0 >。
推送您的工作，包括标记：git push - 标签。
请通过运行git 清洁 -dfx确保您的树是完全干净的。
运行make -f extras / Makefile生成发行包。这将在dist/目录中创建发布包。

生成发行包的散列：

$ cd dist
$ md5sum *
$ sha1sum *
$ sha256sum *

创建包含散列和发布信息的“校验和”文件，Django-<<VERSION>>.checksum.txt。从此模板开始，插入正确的版本，日期，GPG密钥ID（从gpg - list-keys - keyid-format LONG），发布网址和校验和：

This file contains MD5, SHA1, and SHA256 checksums for the source-code
tarball and wheel files of Django <<VERSION>>, released <<DATE>>.

To use this file, you will need a working install of PGP or other
compatible public-key encryption software. You will also need to have
the Django release manager's public key in your keyring; this key has
the ID ``XXXXXXXXXXXXXXXX`` and can be imported from the MIT
keyserver. For example, if using the open-source GNU Privacy Guard
implementation of PGP:

    gpg --keyserver pgp.mit.edu --recv-key XXXXXXXXXXXXXXXX

Once the key is imported, verify this file::

    gpg --verify <<THIS FILENAME>>

Once you have verified this file, you can use normal MD5, SHA1, or SHA256
checksumming applications to generate the checksums of the Django
package and compare them to the checksums listed below.

Release packages:
=================

https://www.djangoproject.com/m/releases/<<RELEASE TAR.GZ FILENAME>>
https://www.djangoproject.com/m/releases/<<RELEASE WHL FILENAME>>

MD5 checksums:
==============

<<MD5SUM>>  <<RELEASE TAR.GZ FILENAME>>
<<MD5SUM>>  <<RELEASE WHL FILENAME>>

SHA1 checksums:
===============

<<SHA1SUM>>  <<RELEASE TAR.GZ FILENAME>>
<<SHA1SUM>>  <<RELEASE WHL FILENAME>>

SHA256 checksums:
=================

<<SHA256SUM>>  <<RELEASE TAR.GZ FILENAME>>
<<SHA256SUM>>  <<RELEASE WHL FILENAME>>

签署校验和文件（gpg - clearsign - digest-algo SHA256 Django - ＆lt； version＆gt； .checksum.txt）。这将生成一个签名文档Django-<version>.checksum.txt.asc，然后您可以使用gpg 验证 t4> Django＆lt； version＆gt； .checksum.txt.asc。

如果您要发布多个发布，请对每个发布重复这些步骤。

Making the release(s) available to the public¶

现在你准备好把发行版放在那里了。去做这个：

将发行包上传到djangoproject服务器，替换A.B. 具有适当的版本号，例如。 1.5版1.5.x版本：
```
$ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
```

上传校验和文件：

$ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt

使用pip和easy_install测试发行版包是否正确安装。这里有一个方法（需要virtualenvwrapper）：

$ RELEASE_VERSION='1.7.2'
$ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`

$ mktmpenv
$ easy_install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ mktmpenv
$ pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ mktmpenv
$ pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION-py2.py3-none-any.whl
$ deactivate

这只是测试tarballs是可用的（即重定向已经启动），并且它们正确安装，但会捕捉到愚蠢的错误。

请IRC上的一些人通过访问校验和文件（例如https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt）来验证校验和，并遵循其中的说明。对于奖励积分，他们还可以解压缩下载的发行版tarball，并验证其内容是否正确（正确的版本号，没有杂乱.pyc或其他不需要的文件）。
将发行包上传到PyPI（对于预发行版，仅上载轮文件）：
```
$ twine upload -s dist/*
```
Go to the Add release page in the admin, enter the new release number exactly as it appears in the name of the tarball (Django-<version>.tar.gz). 所以例如输入“1.5.1”或“1.4c2”等如果发布是LTS分支的一部分，请将其标记为。
让博客帖子宣布发布实况。
For a new version release (e.g. 1.5, 1.6), update the default stable version of the docs by flipping the is_default flag to True on the appropriate DocumentRelease object in the docs.djangoproject.com database (this will automatically flip it to False for all others); you can do this using the site’s admin.
将发布通知发布到django-announce，django-developers和django-users邮件列表。这应该包括一个指向博客文章的链接。如果这是一个安全版本，还包括 OSS-安全 @ T0>列表.OpenWall的.COM.
添加指向#django IRC频道主题的博文的链接：/ msg chanserv 主题 #django 新主题

Post-release¶

你几乎完成！现在剩下要做的是：

在django/__init__.py中再次更新VERSION元组，增加到下一个预期版本的任何值。例如，在释放1.5.1后，将VERSION更新为VERSION = （1， 5， 2， 'alpha'， 0）。
如有必要，请将版本添加到Trac的版本列表（如果是最终版本，请将其设为默认值）。并非所有版本都已声明；采取以前版本的例子。
如果这是安全版本，请更新Archive of security issues，其中包含所解决问题的详细信息。

New stable branch tasks¶

在创建新的稳定分支之后，有几个项目可以做（通常遵循alpha版本）。这些任务中的一些不需要由释放者来完成。

在新版本文档的docs.djangoproject.com数据库中创建新的docs/fixtures/doc_releases.json对象，并更新DocumentRelease JSON夹具，所以人们无法访问生产数据库仍然可以运行docs网站的最新副本。
为新功能版本创建存根发行说明。使用上一个功能版本的存根，或复制上一个功能版本中的内容，并删除大部分只留下标题的内容。
将django.contrib.auth.hashers.PBKDF2PasswordHasher中的默认PBKDF2迭代次数增加约20％（选择一个轮数）。运行测试，并使用新值更新3个失败的哈希测试。确保这在发行说明中被记录（有关示例，请参阅1.8发行说明）。
删除已过期的功能。为了清楚起见，每个删除应在单独的提交中完成。在提交消息中，向原始票证添加“refs #XXXX”，如果可能的话，弃用开始。
去掉 .. versionadded ::, .. versionadded ::，和 .. 弃用:: 两个版本之前的文档中的注释。例如，在Django 1.9中，1.7的注释将被删除。
将新分支添加到阅读文档。由于自动生成的版本名称（“stable-A.B.x”）与我们以前在阅读文档（“A.B.x”）中使用的版本号不同，我们目前要求Eric Holscher为我们添加版本。有一天，“阅读文档”UI可能内置了别名功能。

Notes on setting the VERSION tuple¶

Django的版本报告由django/__init__.py中的VERSION元组控制。这是一个五元组元组，其元素是：

主要版本。
次要版本。
微版。
状态 - 可以是“alpha”，“beta”，“rc”或“final”之一。
序列号，对于按顺序运行的alpha / beta / RC软件包（允许例如“beta 1”，“beta 2”等）。）。

对于最终版本，状态始终为“final”，序列号始终为0。具有“alpha”状态的序列号0将被报告为“前-α”。

一些例子：

（1， 2， 1， 'final'， 0） t5 >→“1.2.1”
（1， 3， 0， 'alpha'， 0） t5 >→“1.3 pre-alpha”
（1， 3， 0， 'beta'， 2） t5 >→“1.3 beta 2”

Django 1.11.6 文档