Skip to main content

Django如何形成?

本文解释如何释放Django。

如果您做出更改,请保持这些说明是最新的! 这里的要点是描述性的,而不是规定性的,所以可以自由地精简或以其他方式做出改变,但 相应地更新此文档!

概述

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

  • 安全版本:披露和修复漏洞。这通常涉及两个或三个同时发布 - 例如。 1.5.x,1.6.x,并且根据时间,可能是1.7α/β/rc。

  • 常规版本:最终版本(例如1.5)或修正版更新(例如1.5.1)。

  • 预发布: 1.6α,β或rc。

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

  1. 如果这是安全版本,请在实际发布前一周预先通知安全通讯组列表。

  2. 校对发行说明,寻找组织和写错误。起草博客文章和电子邮件公告。

  3. 更新版本号并创建发行包。

  4. 将软件包上传到 djangoproject.com 服务器。

  5. 将新版本上传到PyPI。

  6. djangoproject.com 上的管理员中声明新版本。

  7. 发布博客条目并发送电子邮件公告。

  8. 更新版本号后发布。

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

先决条件

在开始之前,您需要一些东西:

  • GPG密钥。如果您要使用的密钥不是默认签名密钥,则需要在下面的每个GPG签名命令中添加 -u you@example.com,其中 you@example.com 是与您要使用的密钥相关联的电子邮件地址。

  • 安装一些必需的Python包:

    $ pip install wheel twine
    
  • 在PyPI上访问Django的记录。使用您的凭据创建文件:

    ~/.pypirc
    [pypi]
    username:YourUsername
    password:YourPassword
    
  • 访问 djangoproject.com 服务器以上传文件。

  • 访问 djangoproject.com 上的管理员作为“站点维护者”。

  • 访问职位到 django-announce

  • 如果这是安全版本,请访问预通知通讯组列表。

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

预发布任务

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

  1. 如果这是安全版本,请在发布前发出预通知 一周。我们维护一个在私人 django-core 存储库中获得这些预通知电子邮件的人员的列表。将邮件发送给 security@djangoproject.com 和BCC预先通知收件人。此电子邮件应该使用您用于发布的密钥进行签名,并且应包括每个已修复问题的修补程序。

  2. 随着发布接近,观察Trac确保没有释放阻滞剂留给即将发布的版本。

  3. 请与其他提交者确认,以确保他们没有任何未提交的版本更改。

  4. 校对发行说明,包括查看在线版本以捕获任何断开的链接或reST错误,并确保发行说明包含正确的日期。

  5. 仔细检查发布说明中是否提到了已弃用的任何API的弃用时间表,并提及Python版本支持中的任何更改。

  6. 仔细检查发行说明索引是否有指向新版本说明的链接;这将在 docs/releases/index.txt

  7. 如果这是功能版本,请确保集成了Transifex的翻译。这通常由单独的翻译的经理而不是释放者完成,但这里是步骤。如果您在Transifex上有一个帐户:

    $ python scripts/manage_translations.py fetch
    

    然后提交更改/添加的文件(.po和.mo)。有时,有验证错误需要调试,因此避免在需要发布之前立即执行此任务。

  8. 更新django-admin手册页:

    $ 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
    

    然后提交更改的手册页。

准备发布

写发布的公告博客文章。您可以随时将其输入到管理员,并将其标记为非活动状态。这里有几个例子:example security release announcementexample regular release announcementexample pre-release announcement

实际上滚动发布

OK,这是有趣的部分,我们实际上推出一个发布!

  1. 检查 Jenkins 是绿色的您正在推出的版本。你可能不应该发布一个版本,直到它的绿色。

  2. 发布始终从发布分支开始,因此您应该确保您处于稳定的分支并且是最新的。例如:

    $ git checkout stable/1.5.x
    $ git pull
    
  3. 如果这是安全版本,请从 django-private 合并相应的修补程序。根据需要重新编写这些补丁,使每个补丁都是发布分支上的简单提交,而不是合并提交。为了确保这一点,将它们与 --ff-only 标志合并;例如:

    $ git checkout stable/1.5.x
    $ git merge --ff-only security/1.5.x
    

    (这假设 security/1.5.xdjango-private 仓库中的一个分支,包含1.5系列中下一个版本的必要安全补丁)。

    如果git拒绝与 --ff-only 合并,请切换到安全补丁分支,并在要将其合并到(git checkout security/1.5.x; git rebase stable/1.5.x)的分支上进行rebase,然后切换回并执行合并。确保每个安全修复程序的提交消息解释该提交是一个安全修复程序,并且将发出公告(example security commit)。

  4. 对于功能版本,请删除发行说明顶部的 UNDER DEVELOPMENT 标题,并将发行日期添加到下一行。对于修补程序版本,请将 *Under Development* 替换为发行日期。在特定版本的发行说明所在的所有分支上进行此更改。

  5. 在版本 django/__init__.py 中更新版本号。有关 VERSION 的详细信息,请参阅下面的 notes on setting the VERSION tuple

  6. 如果这是预发行包,请更新 setup.py 中的“开发状态”trove分类器以反映这一点。否则,请确保分类器设置为 Development Status :: 5 - Production/Stable

  7. 使用 git tag 标记发行版。例如:

    $ git tag --sign --message="Tag 1.5.1" 1.5.1
    

    您可以通过运行 git tag --verify <tag> 来检查您的工作。

  8. 推送您的工作,包括标记:git push --tags

  9. 确保你有一个绝对干净的树通过运行 git clean -dfx

  10. 运行 make -f extras/Makefile 以生成发行包。这将在 dist/ 目录中创建发行包。

  11. 生成发行包的散列:

    $ cd dist
    $ md5sum *
    $ sha1sum *
    $ sha256sum *
    
  12. 创建一个“checksums”文件,Django-<<VERSION>>.checksum.txt 包含散列和发布信息。从此模板开始,插入正确的版本,日期,GPG密钥ID(来自 gpg --list-keys --keyid-format LONG),版本URL和校验和:

    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>>
    
  13. 签署校验和文件(gpg --clearsign --digest-algo SHA256 Django-<version>.checksum.txt)。这将生成一个签名的文档 Django-<version>.checksum.txt.asc,然后您可以使用 gpg --verify Django-<version>.checksum.txt.asc 验证。

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

向公众提供发布

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

  1. 将发行包上传到djangoproject服务器,替换A.B.具有适当的版本号,例如1.5为1.5.x版本:

    $ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
    
  2. 上传校验和文件:

    $ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt
    
  3. 使用 easy_installpip 测试发行包是否正确安装。这里有一个方法(需要 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
    

    这只是测试tarball是可用的(即重定向是up),并且他们正确安装,但它会捕获愚蠢的错误。

  4. 要求IRC上的几个人通过访问校验和文件(例如 https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt)并按照其中的说明验证校验和。对于奖励积分,他们还可以解压缩下载的版本tarball,并验证其内容看起来是正确的(正确的版本号,没有流浪的 .pyc 或其他不受欢迎的文件)。

  5. 将发布包上传到PyPI(对于预发布,只上传wheel文件):

    $ twine upload -s dist/*
    
  6. 转到 Add release page in the admin,输入完全与tarball名称(Django-版本> .tar.gz)中显示的新版本号。因此,例如输入“1.5.1”或“1.4c2”等。如果发布是LTS分支的一部分,则将其标记为。

  7. 让博客帖子宣布发布实况。

  8. 对于新版本版本(例如1.5, 1.6),通过将 docs.djangoproject.com 数据库中相应的 DocumentRelease 对象上的 is_default 标志翻转为 True 来更新文档的默认稳定版本(这将自动将其更改为 False)。你可以使用网站的管理员这样做。

  9. 将发布公告发布到 django-announcedjango-developersdjango-users 邮件列表。这应该包括链接到公告博客文章。如果这是一个安全版本,还包括 oss-security@lists.openwall.com

  10. #django IRC频道主题中添加一个链接到博客文章:/msg chanserv TOPIC #django new topic goes here

发布后

你几乎完成!现在剩下要做的是:

  1. 再次更新 django/__init__.py 中的 VERSION 元组,增加到下一个预期版本的任何值。例如,在释放1.5.1之后,将 VERSION 更新为 VERSION = (1, 5, 2, 'alpha', 0)

  2. 如果需要,在 Trac’s versions list 中添加发布(如果是最终发布,则将其设为默认)。并非所有版本都已声明;以前版本的示例。

  3. 如果这是一个安全版本,请更新 安全问题存档,其中包含所解决问题的详细信息。

新的稳定分支任务

在创建新的稳定分支(通常是在alpha版本之后)时,有几个项目要做。这些任务中的一些不需要由释放者来完成。

  1. docs.djangoproject.com 数据库中为新版本的文档创建一个新的 DocumentRelease 对象,并更新 docs/fixtures/doc_releases.json JSON夹具,因此无法访问生产数据库的人仍然可以运行docs网站的最新副本。

  2. 为新功能部件版本创建存根发行说明。使用之前功能发布版本的存根,或复制上一个功能版本的内容,并删除大部分内容,只留下标题。

  3. django.contrib.auth.hashers.PBKDF2PasswordHasher 中的默认PBKDF2迭代次数增加约20%(选择一个循环数)。运行测试,并使用新值更新3个失败的哈希测试。确保这在发行说明中注明(有关示例,请参见1.8发行说明)。

  4. 删除已过期的功能。为了清楚起见,每个删除应在单独的提交中完成。在提交消息中,向原始票证添加“refs # ”,如果可能的话,弃用开始。

  5. 从两个版本之前的文档中删除 .. versionadded::.. versionadded::.. deprecated:: 注释。例如,在Django 1.9中,将删除1.7的注释。

  6. 将新分支添加到 阅读文档。由于自动生成的版本名称(“stable-A.B.x”)与我们在“阅读文档”(“A.B.x”)历史上使用的版本号不同,我们目前要求Eric Holscher为我们添加版本。有时候,别名功能可能内置到“阅读文档”用户界面中。

关于设置VERSION元组的注意事项

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

  1. 主要版本。

  2. 次要版本。

  3. 微版。

  4. 状态 - 可以是“alpha”,“beta”,“rc”或“final”之一。

  5. 序列号,用于顺序运行的alpha/beta/RC包(允许例如“beta 1”,“beta 2”等)。

对于最终版本,状态始终为“final”,序列号始终为0.具有“alpha”状态的序列号为0的序列号将报告为“pre-alpha”。

一些例子:

  • (1, 2, 1, 'final', 0) →“1.2.1”

  • (1, 3, 0, 'alpha', 0) →“1.3 pre-alpha”

  • (1, 3, 0, 'beta', 2) →“1.3 beta 2”