放行プログラム.

Astropyの現在のリリースプログラムには、自動配布スクリプトといくつかの手動ステップの組み合わせが含まれています。もしすべてでなければ、未来のバージョンはより多くの過程を自動化するだろう。

場合によっては次のいくつかの異なるプロセスがあります。

署名バージョンに関する情報は、ご参照ください GPG署名鍵と署名タグの作成 設定説明については、参照されたい。

標準発表プログラム

これは、Astropy(または完全なエラー修復/保守分岐方法を使用する付属パケット)を発行する標準発行プロセスである。

  1. 次のエラー修復バージョンのためのGitHubマイルストーンを作成し、残りのすべての問題をリリースするバージョンから除外し、マイルストーンを閉じます。主要バージョンが発表される時、以前のメンテナンス分岐の最後のマイルストーンも閉鎖されなければならない。

    注釈

    新しいマイルストーンの作成は、あなたのpingメンテナンス担当者の関連引き出し要求時に完了することができ、メンテナンススタッフは再マイルストーンを選択することができます。

  2. もしGitHub問題トラッカに何かマークがあれば affects-dev ただし、このバージョンに適用される問題があれば、更新してください affects-release それがそうです。同様に、このバージョンにまだ何か問題が残っている場合、それを次の関連マイルストーンに再割り当てしてください。

  3. (主要バージョンのみ適用)使用問題、広報、貢献者数の統計情報が“最新メッセージ”部分を更新することを確認してください。最初の2つについては astropy-procedures repository スクリプト gh_issuereport.py 前回の主要バージョンからの数字を提供することができる。最後の場合、Astropyを更新する必要があるかもしれません .mailmap 文書は，提出するたびに同じ電子メールアドレスを誤って使用してしまう貢献者が多いためである.そのためには最も簡単な方法は命令を実行することです git shortlog -n -s -e すべての投稿者とその電子メールアドレスのリストを表示します。命名誤りの項目または重複項を検索し、それらを追加します .mailmap ファイル(適切な仕様名/電子メールアドレスに一致します。)この操作が完了すると、中の行数を計算することができます git shortlog -s 最終的な投稿者数を得ることができます

  4. また、必ず更新してください docs/credits.rst 文書は、上記のステップのいずれかの新しい貢献者を含むように構成されている。(このステップは、主なバージョンでのみ必要であるが、時間が許す場合、このステップは、エラー修復バージョンに対して実行されてもよい。)

  5. (Astpy専用)ディレクトリを変更することにより、内蔵されているIERS地球自転パラメータとうるうストップウォッチが最新であることを確保します。 astropy/utils/iers/data 実行しています update_builtin_iers.sh それがそうです。以下のコマンドを用いて結果をチェックする git diff (たくさんの行が見つかったら、驚かないでください。 eopc04_IAU2000.62-now 書類変更；これらのデータを定期的に再分析)して提出する。

  6. Gitがバージョンのために作成したタグに署名する必要があるときに使用するために、GPG鍵ペアを有することを確認します。参照してください GPG署名鍵と署名タグの作成 より多くの情報を知ることができます

  7. 1つを得る 清潔な のバージョンです。 astropy core repository それがそうです。つまり、あなたは中間構築ファイルを何も持っていません。新鮮なものを使うか git clone あるいはやる. git clean -dfx それがそうです。

  8. あなたがこれからリリースするバージョンに対応する分岐にいることを確実にします。例えば、バージョン1.2.2がリリースされた場合、確認してください：

    $ git checkout v1.2.x

  9. 持続的な統合サービス(例えば、GitHub動作またはCircleCI)が通信されることを保証する astropy core repository ブラッキー釈放してくれまだ検査しなければならない Azure core package pipeline 車輪を作って v* 木の枝が通っている。また、すべてのテストが実際に実行されることを保証するためにローカルでテストを実行し、TOXを使用して隔離環境で完全なテストを行うことを望むことができるかもしれません。

    $ pip install tox --upgrade
$ TEST_READ_HUGE_FILE=1 tox -e test-alldeps -- --remote-data=any

  10. 編集 CHANGES.rst リリースするバージョンの日付を“未発行”から今日の日付に変更することで、ファイルを作成します。また、このバージョンのChangeLogにはエントリのどの部分も削除されていないことを確認してください。候補バージョンの後に発表されたバージョンについて (テスト版/リリース候補バージョンに対する修正 )であれば、ChangeLog部分のタイトルも置き換えられるべきであり、発行候補バージョンへの言及は除外される。そして使用：これらの変更を追加して提出する

    <use your favorite editor on CHANGES.rst>
$ git add CHANGES.rst
$ git commit -m "Finalizing changelog for v<version>"

  11. 分岐をGitHubに戻します例えば：

    $ git push upstream v1.2.x

    そして、上述したCIサービス(Azureパイプを含む)がまだ通過していることを確実にする。

    注釈

    交換する必要があるかもしれません upstream ここでは astropy または使用されているリモート名でも astropy core repository それがそうです。

  12. マークを使って提出する v<version> 必ずラベルにつけなければなりません -s オプション：：

    $ git tag -s v<version> -m "Tagging v<version>"

  13. ラベルを上に突き上げる astropy core repository **

    $ git push upstream v<tag version>

    注釈

    交換する必要があるかもしれません upstream ここでは astropy または使用されているリモート名でも astropy core repository それがそうです。また、使用 --tags はいの論点です。 git push しかしこれは not そうすることは予期せぬラベルを押すかもしれない。

    この点ですべてがうまくいけば車輪とsdistは Azure core package pipeline PyPIにアップロードします！

  14. タグの車輪構築に何か問題が生じた場合(Release分岐に渡すと、本当にこのようなことは発生しません)、あなたは何の問題も修復しなければなりません。まず、リリースプロセスを終了するために、Releaseへの提出を削除し、作成したタグを削除する必要があります。

    $ git reset --hard HEAD^^^^ # you could also use the SHA hash of the commit before your first changelog edit
$ git tag -d v<version>

    注釈

    その後、同じラベルをGitHubに再プッシュするいかなる操作も強制的にプッシュされるだろう。

Sdistと車輪がアップロードされると、解放が完了します！

おめでとうございます。あなたは発表を完了しました！今はいくつかの整理任務を達成するだけでこの過程を達成することができる。

リリース後のプログラム

  1. リリース·ブランチに戻ります(例えば、 1.2.x )を更新します CHANGES.rst ファイルには次のバージョンの新しい部分が含まれています。そして追加して提出します：

    $ git checkout v1.2.x
<use your favorite editor on CHANGES.rst>
$ git add CHANGES.rst
$ git commit -m "Add v<next_version> to the changelog"

  2. これらの変更をプッシュして送ります astropy core repository **

    $ git push upstream v<version branch>.x

  3. これが現在のバージョンのバージョン(すなわち、更新バージョンと共にサポートされているLTSではない)である場合、新しいバージョンを指すために“安定”分岐を更新してください：

    $ git checkout stable
$ git reset --hard v<version>
$ git push upstream stable --force

  4. Readthedocsを更新して、先ほどリリースされたバージョンのドキュメントを構築します。“admin”タブでこれを見つけることができます。各GitHubタグの横にチェックボックスがあります。検証しなければならない stable Readthedocsバージョンは、新しいバージョンのために正しく構築されています(前のステップが完了すると、自動的にトリガされるはずです)。

  5. パッチバージョンを発行する際には、発行履歴中の以前のRTDバージョンを“Protected”に設定する必要がある。たとえば，v 1.1.2が発行された場合，v 1.1.1を“Protected”に設定する.これは、以前のバージョンがVersionプルダウンリストで見たバージョンリストを混乱させることを防止することができる(以前のバージョンにもかかわらず、彼らのURLを介してアクセスすることができる)。

  6. Astropyのサイトを編集することで index.html “現在のバージョン”リンクを変更し、および/または古いバージョンのリスト(これがLTSエラー修復または新しい主要バージョンである場合)を変更することで、https：//github.com/Asterpy/Asterpy.github.comでページにアクセスすることができます。ウェブサイトの投稿者リストを更新する必要があるかもしれません docs/credits.rst 最初は。

  7. 星象に広報を1枚開く. 師匠 分岐して更新する CHANGES.rst 先ほど実行されたリリース日を反映して、ChangeLogの新しい部分が含まれています。一般的にそのためには最も簡単な方法は git cherry-pick 変更ログは上のリリースが提出される前に提出されます。これをどのようにするかわからない場合は、メンテナンス分岐の関連部分をコピーして貼り付けることが望ましいです CHANGES.rst 師匠になりました。同じ広報でも更新しなければなりません docs/whatsnew/index.rst そして docs/whatsnew/X.Y.rst 既存のテキストを例にとると，発行されたRTDノードにおける“新規機能”文書にリンクされる.

  8. conda-forge 新しいPyPI(安定)バージョンのPRを自動的に開くことができるロボットがあり、フォローして統合する必要があります。同時に、LTSバージョンについては、以下の位置でPRを手動で開く必要があります。 astropy-feedstock それがそうです。これは車輪の処理過程に似ている.当たる conda-forge バッグの準備ができたら、ニシキヘビ保守員に投稿されたバージョンをメールで通知することで、デフォルトチャネルのバージョンを更新することができます。通常、あなたは確実に待つべきです conda-forge そして可能性があります conda 発表前に仕事をしている(このように新しいバージョンを試用したいユーザーはご利用いただけます conda ）。

  9. 更新する. LATEST_ASTROPY_STABLE あるいは…。 ASTROPY_LTS_VERSION 中の変数 ci-helpers ストレージ·バンクが conda セットメニューをご提供しております。

  10. バージョンをZenodoにアップロードします。Zenodo/GitHub統合はGitHubbでの発表に依存するので、これは手動で行われなければならないが、私たちはそうしなかった。したがって、Astropyコアパケットについては、Astropyチーム証明書を使用してZenodoに登録し、転送してください。 existing record それがそうです。クリックして 新版. -バージョンを新しい記録としてアップロードするのではなく、このようにすることが重要であることに注意されたい。今、前のバージョンの詳しい情報が含まれている事前に記入した預金伝票を見るはずです。既存のファイルを削除してから、そのファイルは ファイル.ファイル セクション、クリックします 書類を選択する そして選択します tar.gz アップロードするコアパケットバージョンのファイルをクリックします。 アップロードを始めます それがそうです。本文を発行する前に、フォームにはいくつかのフィールドが更新される必要があります。 出版日. TarファイルがPyPIにアップロードされた日に設定されなければなりません。 タイトル 新しいバージョンの番号を含むように更新されなければなりません バージョン バージョン番号を含むように更新されなければならない(いいえ v 接頭辞).変更にご満足いただけましたら、クリックしてください Save そして、そして 出版する. それがそうです。

  11. バージョンがデフォルトで利用可能になると conda 各チャンネル、公告を準備します。テンプレートとして以前の公告を使用するが，バージョンタグではなくバージョンタグにリンクする. stable それがそうです。新しい主なバージョンについて、あなたはAstropyコーディネーターと調整しなければならない。また、エラー修復バージョンについては、電子メールを送信し続けることができます astropy-dev Astropyメーリングリストです。

テスト版/リリース候補バージョンに対する修正

主要なバージョンについては、真のバージョンが発行される前に重要なエラーを捕捉する機会があるように、テストバージョンおよび/または候補バージョンを選択する。実行中のリリースがこのような事前発行である場合、上記のステップのいくつかを修正する必要があります。

リリースプログラムの主な修正には、以下のことがあります。

  • マークバージョンを入力する際は、含めてください b? あるいは…。 rc?? バージョン番号後の接尾辞，例えば“1.2 b 1”や“1.2 rc 1”である.この番号のプランに従わなければならないということは重要です (X.Yb# あるいは…。 X.Y.Zrc# )は、様々な自動化ツールが主発行前にバージョンを注文することを保証し、PyPIにこれが“事前発行”であることも通知するからである。

  • 中の手順を実行しないでください リリース後のプログラム それがそうです。

候補バージョンが利用可能になったら、以下の位置で新しいWikiページを作成してください Astropy Project Wiki タイトルは“vX.Y RC Testing”(バージョン番号で“X.Y”を置き換える)。 wiki of a previous RC テンプレートとします。

実行機能凍結/分岐の新しい主要バージョン

中で述べたとおり APE2 Astpyバージョンは定期的にリリースされていますが、機能凍結は実際のリリース前に発生しています。特性凍結も，主ノードの開発が新たな主バージョンの保守分岐から分離した場合である.これにより、次の主要バージョンの新しい開発を継続することができ、間もなく発行されるバージョンは、エラー修復および文書更新に集中することができる。

この過程は簡単です

  1. GitHub：最新バージョンを使用するために本地主の枝を更新します

    $ git fetch upstream --tags
$ git checkout -B master upstream/master

  2. 要素を凍結したい位置でメインノードから新しいブランチを作成します。

    $ git branch v<version>.x

  3. 更新する. CHANGES.rst ファイルは、次のメインバージョンの一番上に新しい部分があります。そして、これらの変更を追加して提出します。

    <use your favorite editor on CHANGES.rst>
$ git add CHANGES.rst
$ git commit -m "Add <next_version> to changelog"

  4. 次の主なバージョンを使用して提出をマークしたのは .dev それがそうです。例えば先ほど分岐した場合 4.0 作成します v4.1.dev 提出時に追加する 4.1 節はChangeLogに追加：：

    $ git tag -s "v<next_version>.dev" -m "Back to development: v<next_version>"

  5. 文書中の“新規コンテンツ”部分は、次の主要バージョンの部分を含むように更新される必要がある。例えば：

    $ cp docs/whatsnew/<current_version>.rst docs/whatsnew/<next_version>.rst

    そして、編集する必要があります docs/whatsnew/<next_version>.rst すべてのコンテンツを削除するが，基本構造を保持する.“By the Numbers”の数字を“xxx”に置き換えて、次のバージョンの前に更新することを注意する必要があるかもしれません。そして新しいバージョンを追加します docs/whatsnew/index.rst 更新中の参照 docs/index.rst このバージョンを指してこれらの変更を提出するには、以下の操作を実行してください。

    $ git add docs/whatsnew/<next_version>.rst
$ git add docs/whatsnew/index.rst
$ git add docs/index.rst
$ git commit -m "Added <next_version> whats new section"

  6. これらすべての変更をGitHubにプッシュします：

    $ git push upstream v<version>.x:v<version>.x
$ git push upstream master:master

    注釈

    交換する必要があるかもしれません upstream ここでは astropy または使用されているリモート名でも astropy core repository それがそうです。

  7. GitHub問題トラッカでは、次の主要バージョンに新しいマイルストーンを追加します。

エラー修復バージョンの維持

注釈

つねにLTS発行版から始まり，必要であれば安定発行版のエラー修復に続く.この順序で配布されていない場合には，コンテンツの位置に関する変更ログエントリが混同される可能性がある.

ほとんどのPythonプロジェクトで推奨されるAstropyバージョンは、<main>.<Minor>.<Micro>バージョンスキームに準拠しており、“マイクロ”バージョンは“bug修復”バージョンとも呼ばれています。エラー修復バージョンは、どのユーザにも見えるインタフェースを変更すべきではありません。これらは、前の主要/第2のバージョン上のエラーのみを修復すべきであり、内部APIまたは以前のバージョンの漏れを含む、すなわち、文書には、存在するが意外に前のバージョンから漏れた機能が記録されていることもできる。これらはまた、解像度を向上させる文書文字列の変更を含むことができるが、新しい機能(例えば、より多くの例、タイピングエラー修復など)は記述されていない。

エラー修復バージョンは、一般に、一次ブランチとは独立した1つまたは複数のエラー修復分岐を維持することによって管理される(以下の発行プロセスでは、これらのブランチの作成について議論する)。通常，Astropyマスタノード上の問題が修復されていれば，これがAstropyエラー修復バージョンに含まれるべきかどうかを決定しなければならない.通常、この質問の答えは“はい”であり、bug修復分岐には適用されない可能性があるにもかかわらず、答えは“はい”である。たとえば，初めて誤った修復分岐を作成する際に存在しない新しい機能に修復を移植する必要はない.新しい特性は決して誤った修復分岐に統合されない--誤り修復のみであることから命名された。

ごく少数の場合、エラー修復は、主ノードに進むことなく、直接エラー修復ノードに入ることができる。開発バージョンで削除または書き換えられた機能を修復し，その問題を修復しないと，このようなことが発生する可能性がある.しかしながら、いくつかのユーザは、API変更のために、いくつかのユーザが新しい主要/マイクロバージョンにアップグレードするのが遅い可能性があるので、エラーの深刻さに応じて、エラー修復バージョンに含める価値があるかもしれない。

問題はGitHub問題トラッカ中のマイルストーン機能を介してAstropyバージョンに割り当てられる.任意の所与の時間に、少なくとも2つのバージョンが開発されている：次の主要/サブバージョンおよび次のエラー修復バージョン。たとえば，本稿を作成する際には，v 1.2.2とv 0.3.0の2つの発表マイルストーンがある.この場合，v 1.2.2は次のエラー修復バージョンであり，そのバージョンに修復を含むすべての問題をマイルストーンに割り当てるべきである.新しい特性を実現するすべての問題はv 0.3.0マイルストーンに入ります--これは主枝のどの作業でもあり、後方に移植されるべきではありません。マイルストーンの使用に関するより詳細なガイドラインについては、ご参照ください マイルストーンとラベルを使います それがそうです。

メインプログラムからの立ち退き修復

注釈

The changelog script in astropy-procedures (pr_consistency scripts in particular) does not know about minor releases, thus please be careful. For example, let's say we have two branches (master and v1.2.x). Both 1.2.0 and 1.2.1 releases will come out of the same v1.2.x branch. If a PR for 1.2.1 is merged into master before 1.2.0 is released, it should not be backported into v1.2.x branch until after 1.2.0 is released, despite complaining from the aforementioned script. This situation only arises in a very narrow time frame after 1.2.0 freeze but before its release.

ほとんどの修復は使用されています git cherry-pick コマンドは，パッチのように1回のコミットとは異なる点を適用する.例えば、現在のbug修復分岐は‘v 1.2.x’であり、提出時にmasterでbugが修復されたと仮定する。 abcd1234 それがそうです。修復をサポートするために、v 1.2.x分岐を発行してください(それを確保して astropy core repository )を選択し、適切な提出を選択する：

$ git checkout v1.2.x
$ git pull upstream v1.2.x
$ git cherry-pick abcd1234

誤った修復分岐が異なる開発経路を表しているため，厳選が適用されない場合がある.これは他の統合衝突を解決するように解決できます衝突ファイルを手動で編集して実行します git commit デフォルトでメッセージを提出することを受け入れます厳選されたパッチが単独の提出に関連するChangeLogエントリがあれば、そのエントリもサポートすることを確認してください。

もし問題が一度以上提出しなければ解決できない場合、どうすればいいですか？これにはいくつかの可能性がある。最も簡単なのは，修復が主ノードに統合されたPull要求の形で現れることである.GitHubがPull要求をマージするたびに、マスタノードにおいてマージコミットが生成される。この合併提出表示 full 引き出し要求中のすべての提出数を合わせた差をとる.これは統合提出だけが必要だということを意味します(これは追加が必要です -m 1 Cherry-Pickコマンドのオプション)。例えばもし 5678abcd 合併提出です。

$ git checkout v1.2.x
$ git pull upstream v1.2.x
$ git cherry-pick -m 1 5678abcd

実際，Astropyは引き込み要求に基づくワークフローを強調しているため，これは most 修復後の移植誤りのよく見られる場面も，最も考慮する必要のない場面である.ただし、引込要求として導入されていない修復プログラムを処理後に移植しない場合は、読み続けてください。

参考

合併承諾とさくらんぼ精選 Cherry-Pickコマンドおよび合併提出とどのように使用されるかについてのより多くの説明は、参照されたい。

厳選された統合提出でなければ、複数の提出を処理できる他の選択肢があります。最も簡単な方法は煩雑かもしれないが，Cherry-Pick命令を正しい順序でコミットごとに実行する.しかし，Git 1.7.2から，次のように一連の提出を統合することができる.

$ git cherry-pick 1234abcd..56789def

あなたが選択した提出書が実際にお互いに一致している限り、これはよく働くことができる。多くの場合、いくつかのbug修復は後続の提出に関連するにもかかわらず、これらの提出は後方ポートをサポートする必要がある。バグ修復の多くは，問題トラッカに関連する問題があるため，提出メッセージにその問題に関連するすべての提出が参照されることを確認してください.そうすれば、返送された提出が必要であれば、紛失を避けることはもっと難しくなります。

誤った修復ノードを直接修復する.

本節で前述したように、修復はエラー修復バージョンにのみ適用され、メインライン開発には適用されない場合がある。この場合には2つの選択肢があります

  1. アクセスを提出する権限を持つAstropy開発者 astropy core repository エラー修復分岐を確認し、修復を直接提出してプッシュすることができます。

  2. できれば ：masterのためのプル要求ではなく、giHubを介してbug修復分岐のためのプル要求を開始することもできます。通常ノード上のノードから astropy core repository GitHubは、お客様のブランチをAstropyのマスターと比較します。引き出し要求ページの左側を見ると、“base repo：Astpy/Astpy”の下に“base Branch：master”とラベル付けされたドロップダウンリストがあります。このプルダウンメニューだけをクリックし、エラー修復分岐(例えば、“v 1.2.x”)を選択することができます。その後、GitHubは、あなたの修復をブランチと比較し、PRが受け入れられたときにブランチに統合する。

エラー修復分岐を発表する準備をしています

エラー修復バージョンを作成する前に、2つの主なステップが必要です。このプロセスの残りの部分は、本明細書に記載された任意の他のバージョンと同じである 標準発表プログラム (ただし、正しいバージョン番号を提供することを確認してください)。

  1. リリースマイルストーンに割り当てられた問題の任意の既存の修復(および、以前のLTSバージョン(ある場合))は、発行前に保守ブランチに含まれなければならない。

  2. Astropy ChangeLogは、現在のバージョンで修復されたすべての問題、特にユーザに見える問題をリストするために更新されなければならない。ChangeLogは主ノードで更新され，エラー修復ノードに統合されるべきである.ほとんどの問題は 当然だと思います。 ChangeLogエントリがありますしかしたまにはこれらを忘れてしまうので、まだ存在しなければ、後ろに移植する過程で1つ追加してください。参照してください ログの更新と保守変更 もっと細かいことを知っています。

To aid this process, there are a series of related scripts in the astropy-procedures repository, in the pr_consistency directory. These scripts essentially check that the above two conditions are met. Detailed documentation for these scripts is given in their repository, but here we summarize the basic workflow. Run the scripts in order (they are numbered 1.<something>.py, 2.<something>.py, etc.), entering your github login credentials as needed (if you are going to run them multiple times, using a ~/.netrc file is recommended - see this Stack Overflow post for more on how to do that, or a similar github help page). The script to actually check consistency should be run like:

$ python 4.check_consistency.py > consistency.html

これは、プル要求がmaster内のすべての領域に統合されることが表示される単純なウェブページを生成するであろう。 not そのマイルストーンによって使用される関連バージョンでは、任意の変更ログ違反(すなわち、GitHubマイルストーンによって示されるPRと誤った部分にあるPR)である。あなたはこのような違反を是正したいと思います 1つ目は バックエンドプロセスを起動する前に(必要に応じてスクリプトを再実行する).

世界の終わりの終わり consistency.html そしてページには一連のものが表示されます git cherry-pick マイルストーンとノードを一致させるために必要なPRを使用して分岐を維持する命令を更新する.あなたが支店を正確に維持していることを確認してください。例えば、

$ git checkout v1.3.x
$ git pull upstream v1.3.x  # Or possibly a rebase if conflicts exist

もしあなたが1.3.xシリーズのエラーを修復している場合。上で説明したさくらんぼを選ぶ手順に従って、1つのコマンドを一度にチェックします。もし何かの理由で、あなたがGitHubマイルストーンが間違っていると判断した場合、後方移植は不可能です。GitHubにこの問題を再表示して、続けてください。さらに、PRを後方に移植するたびに、問題に“これをv 1.3.xに後方移植することは<SHA>”と同様のコメントを残すことが有用であり、後方移植が後で見る可能性のある他の人に発生することが明確に分かる。

警告

自動化スクリプトは決して完璧ではなく，後方移植が必要な問題を逃したり，誤報が報告されたりする可能性がある.

Bug修復バージョンが最終的に決定される前に、発表マイルストーンで閉じられた問題リストをGitHubで表示し、各問題がBug修復分岐に修復されているかどうかを検査することは、いつも良い考えである。一般に、1つの迅速な方法は、各問題に対して実行される：

$ git log --oneline <bugfix-branch> | grep #<issue>

ほとんどの修復は、提出メッセージでそれらの関連問題を言及するので、これはしばしばかなり信頼できる。しかし，それらの修復は単独のプル要求で行われるため，ログ提出には発生しない問題がある.一般に，GitHubは交差引用問題とその広報によってこれを明確にする.

最後に、発表マイルストーンに割り当てられたすべての問題が発表前に修復されなければならないわけではない。通常，あるスケジュール内で既存の修復を含むバージョンを発行するためには，すぐに修復されない問題を新たな発表マイルストーンに分類することが望ましい.リリースされるエラー修復バージョンが“v 1.2.2”である場合、引き続き“v 1.2.3”マイルストーンを作成し、“v 1.2.2”でタイムリーに修復したくない任意の問題を再割り当てします。

GPG署名鍵と署名タグの作成

リリースを実行する主なステップの1つは、リリース中のバージョンを表すリポジトリの適切な状態を表すフラグをgitリポジトリに作成することです。Astropyでは常に signed tags ：署名タグは，署名者の名前と電子メールアドレス，日時およびタグ中のコードのチェックサムでアノテーションを行う.次いで、この情報は、GPG秘密鍵を使用して署名され、リポジトリに格納される。

署名ラベルの使用は、将来の使用に備えて、ラベルコンテンツの完全性を保証することができる。Gitのような分散VCSでは、誰でも彼らのリポジトリに“0.1”というAstropyタグを作成することができます--タグを作成した後も、そこをぶらぶらしやすいです。しかし，1つの“0.1”のみがAstropyプロジェクトコーディネーターの1人によって署名され，彼らの公開鍵で検証することができる.

公開鍵/秘密鍵ペアの生成

GitはGPGを使用して署名タグを作成するので、Astropyバージョンを実行するためには、GPGをインストールする必要があり、署名鍵ペアを生成しなければならない。*NIX実装の多くは、(システムパッケージの完全性を検証するために使用されるので)GPGをデフォルトでインストールしています。もしあなたがいなければ gpg コマンド、このコマンドをどのようにインストールするかに関する情報は、あなたのシステムのドキュメントを参照してください。

OSXでは，以下のコマンドを用いてMacPortsからGPGを実装することができる. sudo port install gnupg それがそうです。

新しい公開鍵/秘密鍵ペアを作成するには、実行してください：

$ gpg --gen-key

これはあなたにいくつかの対話段階をもたらすだろう。暗号化および期限切れ設定については、デフォルト設定を使用することは安全であるはずです(私は鍵サイズ4096を使用していますが、数キロバイト多いので何か害があるのですか？)フルネームを入力するには、中間名または中間名の頭文字と、一定期間アクティブ状態を希望する電子メールアドレスが含まれています。この名前および電子メールアドレスは、提供されているGIT構成情報と一致しなければならないので、鍵を作成する際に同じ名前/電子メールアドレスを選択するか、または鍵情報を一致させるためにGIT構成を更新しなければならないことに注意されたい。最後に、非常に良い暗号フレーズを選択して、それは簡単に暴力的な攻撃を受けないだろう。

同じ鍵を一定期間使用したい場合は、公開鍵と秘密鍵を同時にバックアップすることが望ましい：

$ gpg --export --armor > public.key
$ gpg --export-secret-key --armor > private.key

これらのファイルは、信頼された位置にバックアップされ、好ましくは、ある場所に安全に格納可能な使い捨て書き込み物理媒体である。人々はまた、彼らの鍵を信頼されたオンライン暗号化ストアにバックアップすることもできますが、安全ではないと思う人もいるかもしれませんが、これはあなたとあなたが満足している点に依存します。

公開鍵を鍵サーバに追加します

公開鍵があれば、電子メール、共通コードベースなど、お好きな場所に公開することができます。専用のパブリックOpenPGP鍵サーバにアップロードすることもできます。これは、(手動で撤回されるまで)公開鍵を無期限に格納し、世界各地の他の鍵サーバと自動的に同期するであろう。これにより，gpgコマンド実行ツールを用いて公開鍵を検索することが容易になる.

そのためには、公開鍵の鍵名が必要です。この情報を検索するには、入力してください：

$ gpg --list-keys

これは出力と同様になります

/path/to/.gnupg/pubring.gpg
---------------------------------------------
pub   4096D/1234ABCD 2012-01-01
uid                  Your Name <your_email>
sub   4096g/567890EF 2012-01-01

行の“pub”で始まる8桁の16進数--本例では、あなたの公開鍵の唯一のキーワード名“1234 ABCD”です。これを鍵サーバにプッシュするには，入力してください：

$ gpg --send-keys 1234ABCD

ただし、1234 ABCDは、あなたの公開鍵の鍵名に置き換えられます。ほとんどのシステムは、合理的なデフォルト鍵サーバを構成しているので、これ以上指定する必要はありません。

マークを作成する

現在，GITで署名タグを作成することをテストした.これは安全です--マークをリモート·リポジトリにプッシュする前に削除することができます：

$ git tag -s v0.1 -m "Astropy version 0.1"

これは、タグに署名するために、パスワードを入力して、あなたの秘密鍵をロック解除することを要求するであろう。Gitによって選択されたデフォルト署名鍵が正しいことを確認します(鍵が1つしかない場合は正しい)。

タグを作成した後、以下のコマンドを使用して検証することができます。

$ git tag -v v0.1

これは同じように出力されるはずです

object e8e3e3edc82b02f2088f4e974dbd2fe820c0d934
type commit
tag v0.1
tagger Your Name <your_email> 1339779534 -0400

Astropy version 0.1
gpg: Signature made Fri 15 Jun 2012 12:59:04 PM EDT using DSA key ID 0123ABCD
gpg: Good signature from "Your Name <your_email>"

あなたの鍵リングに署名者の公開鍵がある限り，それを用いて任意のリポジトリからの署名タグを検証することができる.本例では、あなた自身がタグに署名しているので、あなたはすでに公開鍵を持っています。

以下の手順でリリースを予定している場合は、配布スクリプトがこの操作を実行しますので、作成したばかりのタグを削除する必要があります。以下の操作を実行することで、このタグを削除することができます。

$ git tag -d v0.1