リリースの手順

  1. リリース作業の開始
  2. RC作成とその後
  3. リリース作業
  4. コードフリーズについて

TeraTerm Project でのリリース手順について以下に示します。

リリース作業の開始

  1. チケット、ブランチなどを確認する
  2. ツール、ライブラリ、インポート元の最新版をチェックする

    リリースビルドには CI ツールを使っているため、Visual Studio の詳細バージョンはコントロールできない。どのバージョンになるかは、ビルド時点で CI ツールがどのバージョンを採用しているかに左右される。

    リリースに使うライブラリのバージョンはこの時点でおおむね決定する。

    安定版リリースでは、ライブラリは元になった定期リリースから更新しない。（ライブラリにセキュリティ修正がある場合は個別に検討する。）

  3. 今回のリリースに入れたいものが落ち着く

RC 作成とその後

  1. RC 作業ブランチを作成する（main ブランチ、または安定版リリース用ブランチから） 
    git switch main
git pull --rebase
git checkout -b release/5_6_0-RC
  2. ドキュメントを確認する
  3. この年における最初のリリースの場合は、著作権表示の「最後の発行の年」をインクリメントする 例: 年をインクリメントするコミット
  4. バージョンをインクリメントする 例: バージョンをインクリメントするコミット
  5. インストーラを作成する（確認用）
  6. サポートされている全 OS でインストーラの実行、起動、接続をチェックする
  7. コミット、push する
  8. 作業ブランチをマージするための Pull Request を作成する
  9. Pull Request をマージする（main ブランチ、または定期リリース用ブランチへ）
  10. GitHub Actions で workflow が実行されてビルドされる
    ビルドは3回実行されます: 例: ビルド 1, 2, 3
    RC の作成では「マージコミットによるビルドバイナリ」を RC 成果物とします。
  11. RCの作成をアナウンスする
  12. 作業ブランチを削除する
  13. フィードバックを受け入れる
    修正が入ったら再度「ドキュメントを確認する」「サポートされている全 OS で起動・接続チェックする」
  14. RC2 を出す場合は、この項目の手順を作業ブランチの作成から再度行う

リリース作業

  1. アナウンス文面を考えておく
  2. 作業ブランチを作成する（main ブランチ、または安定版リリース用ブランチから） 
    git switch main
git pull --rebase
git checkout -b release/5_6_0
  3. ドキュメントを確認する (詳細は同上)
  4. リリース日を変更し、"RC" を削除する ("コメントアウトした dev" にする) 例: リリース日を変更し、"RC" を削除するコミット
  5. インストーラを作成する（確認用）
    ビルド・インストーラの生成がエラーなくできることを確認する。
  6. push する *
  7. 作業ブランチをマージするための Pull Request を作成する *
  8. Pull Request をマージする（main ブランチ、または定期リリース用ブランチへ） *
  9. タグを作成し、push する *
    タグは annotated tags とする。
    タグ名は「v(バージョン)」。（例: 5.6.0ならば "v5.6.0" ） 
    git switch main
git pull --rebase
git tag -a v5.6.0 -m "Release 5.6.0"
git push origin v5.6.0
  10. GitHub Actions で workflow が実行されてビルドされる
    ビルドは4回実行されます: 例: ビルド 1, 2, 3, 4
    リリースでは「タグの作成によるビルドバイナリ」をリリース成果物とします。
    リリース時には workflow が SignPath にコード署名をリクエストしますが、SignPath の release-signing ポリシーは手動で承認が必要です。そのため workflow は途中で署名リクエストが承認されるのを待ちます。したがって、SignPath.io にログインしておき、署名リクエストを Approve します。
  11. 作業ブランチを削除する
  12. GitHub の Releases に追加する
  13. ウイルス対策ソフトの検知を確認する
  14. プロジェクトWebページ (https://teratermproject.github.io) を更新する
    更新のしかたは プロジェクトページの更新手順 を参照
  15. リリースをアナウンスする
  16. 安定版ブランチを作成し、push する（定期リリースの場合のみ） 
    git switch main
git pull --rebase
git checkout -b stable_5_6
git push -u origin stable_5_6
  17. 次のリリースに向けてバージョンをインクリメントする

    定期リリースの場合

    安定版リリースの場合

  18. 変更履歴を修正する（安定版リリースの場合のみ）
    main ブランチを修正する。
    安定版リリースの変更履歴をコピーし、安定版に組み込んだ修正の変更履歴を定期リリースからは削除する。 
    git switch main
git pull --rebase
git checkout -b port/changelog
  19. GitHub の Milestones を調整する（定期リリースの場合のみ） 安定版リリースのマイルストーンは作成しません。
  20. インストーラバイナリのダウンロードに関する確認をする
    ダウンロードしたファイルを実行すると、SmartScreen が「WindowsによってPCが保護されました」という警告を出すことがある。
    これが解消されないと、窓の杜はインストーラを掲載しない。
    Microsoft Edge でダウンロードすると、SmartScreen が「一般的にダウンロードされていません」という警告を出す。
    ウイルス対策ソフトが誤検出することがある。
    keycode.exe がキーロガーとして検出されやすいらしい。
    Microsoft には誤検出の申し立てができる。「PCが保護されました」の解消のため報告する。
    • Microsoft アカウントでログインする
    • https://www.microsoft.com/en-us/wdsi/filesubmission にアクセスする
    • "Software developer" を選んで報告する
  21. Chocolatey (https://community.chocolatey.org/packages/teraterm5) を更新する
    更新のしかたは wiki の Chocolatey を参照
    ウイルス対策ソフトに検出されている状態だと push したバイナリが公開差し止めになることがある。
    同じバージョンを複数回 push できないようなので、push 作業をミスることができない。

コードフリーズについて

コードフリース中は、原則的には致命的なバグの修正のみ可能となります。
コードフリーズは、RC作成（teraterm.iss に RC を付けるコミット）から（バージョンをインクリメントするコミット）までとします。