Djangoはどのように形成されますか？

このドキュメントでは、Djangoをリリースする方法について説明します。

変更を加える場合は、これらの手順を最新の状態に保ってください！ここでのポイントは、説明的であり、規範的ではないため、合理化またはその他の方法で自由に変更してください。ただし、それに応じてこのドキュメントを更新してください。！

概要

作成する必要のあるリリースには、次の3つのタイプがあります。

セキュリティリリース：脆弱性の開示と修正。これには通常、2つまたは3つの同時リリースが含まれます。 1.5.x、1.6.x、およびタイミングに応じて、おそらく1.7 alpha / beta / rc。
通常バージョンのリリース：最終リリース（例： 1.5）またはバグ修正の更新（例： 1.5.1).
プレリリース：例 1.6アルファ、ベータ、またはrc。

関連する手順の短いバージョンは次のとおりです。

これがセキュリティリリースの場合は、実際のリリースの1週間前にセキュリティ配布リストに事前に通知してください。
リリースノートを校正し、構成を探し、エラーを書き込みます。ブログ投稿と電子メールアナウンスをドラフトします。
バージョン番号を更新し、リリースパッケージを作成します。
パッケージをdjangoproject.comサーバーにアップロードします。
新しいバージョンをPyPIにアップロードします。
djangoproject.comの管理者で新しいバージョンを宣言します。
ブログエントリを投稿し、電子メールのお知らせを送信します。
リリース後にバージョン番号を更新します。

詳細はたくさんありますので、お読みください。

前提条件

始める前に、いくつかのことが必要になります。

GPGキー。使用するキーがデフォルトの署名キーではない場合は、以下のすべてのGPG署名コマンドに-u [email protected]を追加する必要があります。ここで、[email protected]は必要なキーに関連付けられたメールアドレスです。使用する。
いくつかの必要なPythonパッケージのインストール：
```
$ python -m pip install wheel twine
```
PyPIに関するDjangoのレコードへのアクセス。クレデンシャルを使用してファイルを作成します。
〜/ .pypirc
```
[pypi]
username:YourUsername
password:YourPassword
```
djangoproject.comサーバーにアクセスしてファイルをアップロードします。
「サイトメンテナ」としてdjangoproject.comの管理者にアクセスします。
django-announceへの投稿へのアクセス。
これがセキュリティリリースの場合は、事前通知配布リストにアクセスしてください。

これが初めてのリリースである場合は、別のリリース担当者と調整して、これらすべてを揃える必要があります。

プレリリースタスク

リリースプロセスを開始する前に、いくつかの項目に注意する必要があります。このようなものはリリースの約1週間前に始まります。そのほとんどは、実際のリリースに至るまでいつでも実行できます。

これがセキュリティリリースの場合は、リリースの1週間前に事前通知を送信してください。そのメールのテンプレートと受信者のリストは、プライベートdjango-security GitHubwikiにあります。 BCC事前通知の受信者。リリースに使用するキーを使用してメールに署名し、 CVE ID （ベンダー：djangoproject、製品：djangoでリクエスト）と修正される各問題のパッチを含めます。また、 django-announce に今後のセキュリティリリースを通知します。
リリースが近づいたら、Tracを監視して、次のリリースのリリースブロッカーが残っていないことを確認します。
他のコミッターに、リリースに対してコミットされていない変更がないことを確認してください。
オンラインバージョンを調べてリンク切れやreSTエラーを検出するなど、リリースノートを校正し、リリースノートに正しい日付が含まれていることを確認します。
リリースノートに、非推奨と記載されているAPIの非推奨のタイムラインが記載されていること、およびPythonバージョンサポートの変更が記載されていることを再確認してください。
リリースノートのインデックスに新しいリリースのノートへのリンクがあることを再確認してください。これはdocs/releases/index.txtにあります。
これが機能リリースである場合は、Transifexからの翻訳が統合されていることを確認してください。これは通常、リリーサーではなく別の翻訳マネージャーによって行われますが、手順は次のとおりです。 Transifexのアカウントをお持ちの場合：
```
$ python scripts/manage_translations.py fetch
```
次に、変更/追加されたファイル（.poと.moの両方）をコミットします。デバッグが必要な検証エラーがある場合があるため、リリースが必要になる直前にこのタスクを実行することは避けてください。
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
```
次に、変更されたマニュアルページをコミットします。
これが新しいシリーズのアルファリリースである場合は、mainから新しい安定したブランチを作成します。たとえば、Django 3.1をリリースする場合：
```
$ git checkout -b stable/3.1.x origin/main
$ git push origin -u stable/3.1.x:stable/3.1.x
```
同時に、安定版ブランチのdocs/conf.pyのdjango_next_version変数を更新して、新しい開発バージョンを指すようにします。たとえば、stable/4.2.xを作成するときは、新しいブランチでdjango_next_versionを'5.0'に設定します。
これが新しいシリーズの「ドットゼロ」リリースである場合は、 django-docs-translations リポジトリの現在の安定したブランチから新しいブランチを作成します。たとえば、Django 2.2をリリースする場合：
```
$ git checkout -b stable/2.2.x origin/stable/2.1.x
$ git push origin stable/2.2.x:stable/2.2.x
```

リリースの準備

リリースの発表ブログ投稿を書いてください。いつでも管理者に入力して、非アクティブとしてマークすることができます。次にいくつかの例を示します。セキュリティリリースのお知らせの例、通常のリリースのお知らせの例、プレリリースのお知らせの例。

実際にリリースをローリング

OK、これは楽しい部分です。実際にリリースをプッシュします。

出すバージョンの Jenkins が緑色になっていることを確認してください。おそらく、緑色になるまでリリースを発行するべきではありません。
リリースは常にリリースブランチから開始されるため、安定したブランチを使用して最新の状態になっていることを確認する必要があります。例えば：
```
$ git checkout stable/1.5.x
$ git pull
```
これがセキュリティリリースの場合は、django-securityの適切なパッチをマージします。必要に応じてこれらのパッチをリベースして、マージコミットではなく、リリースブランチで各パッチをプレーンコミットにします。これを確実にするには、それらを--ff-onlyフラグとマージします。例えば：
```
$ git checkout stable/1.5.x
$ git merge --ff-only security/1.5.x
```
（これは、security/1.5.xがdjango-securityリポジトリのブランチであり、1.5シリーズの次のリリースに必要なセキュリティパッチが含まれていることを前提としています。）

gitが--ff-onlyとのマージを拒否した場合は、セキュリティパッチブランチに切り替えて、マージしようとしているブランチ（git checkout security/1.5.x; git rebase stable/1.5.x）に基づいてリベースしてから、元に戻してマージを実行します。各セキュリティ修正のコミットメッセージで、コミットがセキュリティ修正であり、アナウンスが続くことを説明していることを確認してください（：commit： `セキュリティコミットの例 ` ）。
機能リリースの場合は、リリースノートの上部にあるUNDER DEVELOPMENTヘッダーを削除し、次の行にリリース日を追加します。パッチリリースの場合は、*Under Development*をリリース日に置き換えてください。特定のバージョンのリリースノートが配置されているすべてのブランチでこの変更を行います。
リリースのdjango/__init__.pyのバージョン番号を更新します。 VERSIONの詳細については、以下のVERSIONタプルの設定に関する注記を参照してください。
これがプレリリースパッケージの場合は、setup.cfgの「開発ステータス」トローブ分類子を更新してこれを反映させます。それ以外の場合は、分類子がDevelopment Status :: 5 - Production/Stableに設定されていることを確認してください。
git tagを使用してリリースにタグを付けます。例えば：
```
$ git tag --sign --message="Tag 1.5.1" 1.5.1
```
git tag --verify <tag>を実行して作業を確認できます。
タグgit push --tagsを含めて作業をプッシュします。
git clean -dfxを実行して、完全にクリーンなツリーがあることを確認してください。
make -f extras/Makefileを実行して、リリースパッケージを生成します。これにより、dist/ディレクトリにリリースパッケージが作成されます。
リリースパッケージのハッシュを生成します。
```
$ cd dist
$ md5sum *
$ sha1sum *
$ sha256sum *
```

ハッシュとリリース情報を含む「チェックサム」ファイルDjango-<<VERSION>>.checksum.txtを作成します。このテンプレートから始めて、正しいバージョン、日付、GPGキーID（gpg --list-keys --keyid-format LONGから）、リリースマネージャーのGitHubユーザー名、リリース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

or via the GitHub API:

    curl https://github.com/<<RELEASE MANAGER GITHUB USERNAME>>.gpg | gpg --import -

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-<version>.checksum.txt）に署名します。これにより、署名されたドキュメントDjango-<version>.checksum.txt.ascが生成され、gpg --verify Django-<version>.checksum.txt.ascを使用して確認できます。

複数のリリースを発行する場合は、リリースごとにこれらの手順を繰り返します。

リリースを一般に公開する

これで、実際にリリースを公開する準備が整いました。これをする：

ABを置き換えて、リリースパッケージをdjangoprojectサーバーにアップロードします適切なバージョン番号で、例えば 1.5.xリリースの場合は1.5：
```
$ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
```
これが新しいシリーズのアルファリリースである場合は、ディレクトリABを作成する必要があります

チェックサムファイルをアップロードします。

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

easy_installおよびpipを使用して、リリースパッケージが正しくインストールされることをテストします。これが1つの方法です：

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

$ python -m venv django-easy-install
$ . django-easy-install/bin/activate
$ easy_install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ python -m venv django-pip
$ . django-pip/bin/activate
$ python -m pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION.tar.gz
$ deactivate
$ python -m venv django-pip-wheel
$ . django-pip-wheel/bin/activate
$ python -m pip install https://www.djangoproject.com/m/releases/$MAJOR_VERSION/Django-$RELEASE_VERSION-py3-none-any.whl
$ deactivate

これは、タールボールが利用可能であることをテストするだけです（つまりリダイレクトはアップしています）、正しくインストールされますが、ばかげた間違いをキャッチします。

チェックサムファイルにアクセスして、IRCの数人にチェックサムを確認するように依頼します（例： https://media.djangoproject.com/pgp/Django-1.5b1.checksum.txt ）そしてその中の指示に従ってください。ボーナスポイントとして、ダウンロードしたリリースtarballを解凍し、その内容が正しいように見えることを確認することもできます（適切なバージョン番号、漂遊.pycまたはその他の望ましくないファイル）。
リリースパッケージをPyPIにアップロードします（プレリリースの場合は、ホイールファイルのみをアップロードします）。
```
$ twine upload -s dist/*
```
に移動します管理者にリリースページを追加する、tarballの名前に表示されているとおりに新しいリリース番号を正確に入力します（Django- .tar.gz）。したがって、たとえば「1.5.1」または「1.4c2」などと入力します。リリースがLTSブランチの一部である場合は、そのようにマークします。

これが新しいシリーズのアルファリリースである場合は、 final リリースのReleaseオブジェクトも作成し、 Release date フィールドが空白であることを確認して、 unreleasedとしてマークします。 。たとえば、3.1a1のリリースオブジェクトを作成する場合は、[リリース日]フィールドを空白にして3.1も作成します。
リリースを発表するブログ投稿を公開します。
新しいバージョンのリリースの場合（例： 1.5、1.6）、docs.djangoproject.comデータベースの適切なDocumentReleaseオブジェクトでis_defaultフラグをTrueに切り替えて、ドキュメントのデフォルトの安定バージョンを更新します（これにより、他のすべての場合は自動的にFalseに反転します）。これは、サイトの管理者を使用して行うことができます。

以前のリリースのエントリがある言語ごとに、新しいDocumentReleaseオブジェクトを作成します。 django-docs-translationsリポジトリの現在の安定したブランチからmanage_translations.py robots_txtからエントリをコピーして、djangoproject.comの robots.docs.txt ファイルを更新します。たとえば、Django 2.2をリリースする場合：
```
$ git checkout stable/2.2.x
$ git pull
$ python manage_translations.py robots_txt
```
リリースアナウンスを django-announce 、 django-developers 、および django-users メーリングリストに投稿してください。これには、アナウンスのブログ投稿へのリンクが含まれている必要があります。
これがセキュリティリリースの場合は、 [email protected] に別のメールを送信してください。説明的な件名、たとえば「Django」とリリースノートの問題タイトル（CVE IDを含む）を提供します。メッセージ本文には、アナウンスのブログ投稿テキストなど、脆弱性の詳細を含める必要があります。発表のブログ投稿へのリンクを含めます。
#django IRCチャネルのトピックにブログ投稿へのリンクを追加します：/msg chanserv TOPIC #django new topic goes here。

リリース後

ほぼ終わりです！今やるべきことは次のとおりです。

django/__init__.pyのVERSIONタプルを再度更新し、次に予想されるリリースに増分します。たとえば、1.5.1をリリースした後、VERSIONをVERSION = (1, 5, 2, 'alpha', 0)に更新します。
必要に応じて Tracのバージョンリストにリリースを追加します（必要に応じて、code.djangoproject.comの trac.ini のdefault_version設定を変更してデフォルトにします）。最終リリース）。新しいXYバージョンはアルファリリース後に追加する必要があり、デフォルトバージョンは「ドットゼロ」リリース後に更新する必要があります。
これがセキュリティリリースであった場合は、セキュリティ問題のアーカイブを更新して、対処された問題の詳細を示します。

新しい安定したブランチタスク

新しい安定したブランチの作成後（多くの場合、アルファリリース後）に行うべきいくつかの項目があります。これらのタスクの一部は、リリース担当者が実行する必要はありません。

docs.djangoproject.comデータベースに新しいバージョンのドキュメント用の新しいDocumentReleaseオブジェクトを作成し、docs/fixtures/doc_releases.json JSONフィクスチャを更新して、本番DBにアクセスできないユーザーでも実行できるようにします。 -ドキュメントサイトの最新のコピー。
新機能バージョンのスタブリリースノートを作成します。以前の機能リリースバージョンのスタブを使用するか、以前の機能バージョンのコンテンツをコピーして、見出しのみを残してほとんどのコンテンツを削除します。
django.contrib.auth.hashers.PBKDF2PasswordHasherのデフォルトのPBKDF2反復を約20％増やします（ラウンド数を選択してください）。テストを実行し、失敗した3つのハッシャーテストを新しい値で更新します。これがリリースノートに記載されていることを確認してください（例については、1.8リリースノートを参照してください）。
非推奨サイクルの終わりに達した機能を削除します。明確にするために、各削除は個別のコミットで実行する必要があります。コミットメッセージで、可能であれば非推奨が開始された元のチケットに「refs＃XXXX」を追加します。
2つ前のリリースのドキュメントで、.. versionadded::、.. versionadded::、および.. deprecated::の注釈を削除します。たとえば、Django 1.9では、1.7のメモが削除されます。
新しいブランチを Read the Docs に追加します。自動生成されたバージョン名（「stable-ABx」）は、Read the Docs（「ABx」）で使用されているバージョン名とは異なるため、新しいバージョンを要求するチケットを作成します。
PyPI で新しい分類子をリクエストします。たとえば、Framework :: Django :: 3.1。

VERSIONタプルの設定に関する注意事項

Djangoのバージョンレポートは、django/__init__.pyのVERSIONタプルによって制御されます。これは5要素のタプルであり、その要素は次のとおりです。

メジャーバージョン。
マイナーバージョン。
マイクロバージョン。
ステータス–「alpha」、「beta」、「rc」、「final」のいずれかになります。
順番に実行されるalpha / beta / RCパッケージのシリーズ番号（たとえば、「beta 1」、「beta 2」などを許可）。

最終リリースの場合、ステータスは常に「最終」であり、シリーズ番号は常に0です。「アルファ」ステータスのシリーズ番号0は、「プレアルファ」として報告されます。

いくつかの例：

(1, 2, 1, 'final', 0)→「1.2.1」
(1, 3, 0, 'alpha', 0)→「1.3プレアルファ」
(1, 3, 0, 'beta', 2)→「1.3ベータ2」

Djangoはどのように形成されますか？ —Djangoドキュメント

目次