Skip to content
tickle edited this page Dec 3, 2023 · 23 revisions

| < ライフサイクルポリシー | リリースまでの流れ || Ruffleの使い方 > |

リリースまでの流れ / Release Procedures

  • Dancing☆Onigiri (CW Edition)では、作品別に独自のカスタム(利用者定義)が入ることがあるため、
    「直近の変化点」「最近追加・変更された機能」「更新時の留意事項」といった情報が必要。
    単にリリースするだけではなく、変更経緯が辿れるように各種リンクも合わせて更新している。

通常更新時の対応事項

0. 準備するもの

1. 変更ファイルに対してバージョン名と日付を更新し、developブランチにcommit

1-1. 現行バージョンの場合

  • /js/danoni_main.js
    • Revised, g_version, g_revisedDateの3か所を更新する。
  • /js/lib/danoni_constants.js (変更した場合)
    • このファイルを変更した場合、Revised の日付及びバージョンを更新する。
  • /js/template/danoni_setting.js
    • このファイルを変更した場合、Template Update の日付を更新する。
  • SECURITY.md
    • バージョン変更に合わせ、リンク先のバージョン名を更新する。
      メジャーバージョンアップ時は更新終了バージョンの変更・反映も行う。
  • package.json
    • バージョン変更に合わせ、"version"のバージョン名を更新する。
  • ここでは表記していないが、danoni_main.cssなど他ファイルを更新した場合も
    日付・バージョン名を更新する。

1-2. 過去バージョン(サポートバージョン)の場合

  • バージョン別のsupportブランチ(例: support/v29)に対して直接commitする。
  • バージョン名が異なるだけで、変更対象は同じ。

2. developブランチからmasterブランチへPull Requestを送り、マージする

2-1. 現行バージョンの場合

  • Pull Request名は [バージョン名] 変更内容の概要の形式にする。
  • このバージョンまでにマージされたPull Requestをリストにして記載する。
    ここでリスト化しておくと、リスト化したPull Request側でどのバージョンで反映したかが後で追えるので便利。
## :hammer: 変更内容 / Details of Changes
- #1416 
- #1417 
- #1418 

2-2. 過去バージョン(サポートバージョン)の場合

  • supportブランチは独立したブランチのため、他のブランチへのPull Requestやマージは絶対に行わないこと。

3. masterとdevelopブランチを同期化し、masterへのマージコミットに対してタグを生成

  • masterブランチだけマージコミット分が増えているので、developブランチにmasterブランチを逆マージする。
  • Gitクライアントでforkを使っている場合、一度Fetchした上でマージコミットに対して「Merge into 'develop'」する。
  • その後、masterへのマージコミットに対して「New Tag」でタグを生成し、名前をバージョン名 (例: v30.3.0など) にして「Push」する。

4. リリースノートの作成

4-1. 現行バージョンの場合

  • リリースノートを1から作るのは手間のため、前回のリリースノートを編集してコピーする。
  • Chrome拡張: Find & Replace for Text Editing を使ってバージョン名を一斉置換する。
    Changelogのリンクはバージョン名で置換できないため、手動で修正する。
Changelog-latest#v3030-2023-03-01  // バージョン名のドットを取って、更新日を付与する
Changelog-v29#v2941-2023-01-28
  • File changedについて、今回変更したファイルに合わせてリンクを修正する。
    変更しない場合は、最終更新したバージョンのReleaseリンクを張る。
**v30.3.0** <- 最新バージョンで変更するファイル
[v30.1.1](https://github.com/cwtickle/danoniplus/releases/tag/v30.1.1) <- 今回更新しないファイル(最終で更新したバージョンとリンクをつける)
  • danoni_setting.jsの場合は、前回変更したファイルのバージョン名を控え、compareリンクを作成する。
    下記は、前回変更したバージョンがv27.1.0で、変更先がv30.1.1である例。
|/js/template|[danoni_setting(-template).js](https://github.com/cwtickle/danoniplus/compare/v27.1.0...v30.1.1#files_bucket)|[📥](https://github.com/cwtickle/danoniplus/releases/download/v30.1.1/danoni_setting-template.js)|[v30.1.1](https://github.com/cwtickle/danoniplus/releases/tag/v30.1.1)|
  • マージされた内容を New Features, Improvements, Bug Fixes に振り分ける。 参照先の Pull Request の番号をリンクさせる。
  • 今回の更新で留意が必要な点を「Remarks」として記載する。
    あらかじめ元となるPull Requestに仕様や変更理由を記入しておくと、そのまま利用しやすい。
  • 直近のバージョンリンクを「Recent Changes」に追加する。
  • バグフィックス系の場合は過去バージョンも修正するので、過去バージョンのリリースノート及び影響元のリリースノートへのリンクを付与する。
  • 変更ファイルを「Download asset」としてファイルアップロードする。
    「danoni_setting.js」が変更対象の場合は、ファイルを上書きしてしまうと
    既存の設定が上書きされ問題になるため、
    「danoni_setting-template.js」に名前を変更してアップロードする。

4-2. 過去バージョン(サポートバージョン)の場合

  • 基本的な流れは 4-1.と同じだが、参照するリリースノートは過去バージョンのものを使用すること。
  • リンク形式や仕様が他と異なっているため。

  • バージョン比較対象は、現行バージョンの場合はmasterブランチだが、過去バージョンの場合はsupportブランチになる。 v29の場合、support/v29が比較対象となる。
[vs. latest v29](https://github.com/cwtickle/danoniplus/compare/v29.4.2...support/v29#files_bucket)

4-3. 更新終了バージョンに対して情報追記

  • 過去バージョンに影響のある不具合の場合、更新終了バージョンの不具合情報に関係リンクを追記する。
    その不具合を修正したバージョンと対応するPull Request(無い場合は、前回バージョンとの差分)を記載する。
  • 影響するバージョン全てに対して同じ内容を記載する。英語版もv19以降について対応する。
<!-- 通常例 -->
- 譜面リストで、上下キーを使って選択した譜面がキー数違いのときにキーコンフィグ画面へ移動すると画面が止まる ⇒ ( [v31.0.1](https://github.com/cwtickle/danoniplus/releases/tag/v31.0.1) / [fix](https://github.com/cwtickle/danoniplus/pull/1446) )

<!-- Pull Requestが存在しない例 -->
- 11, 11Lkeyの別キーモードでFlatにしたときにスクロールが想定と逆に流れる ⇒ ( [v29.4.3](https://github.com/cwtickle/danoniplus/releases/tag/v29.4.3) / [fix](https://github.com/cwtickle/danoniplus/compare/v29.4.2...v29.4.3) )

5. Changelogの作成

  • リリースノートのうち、「File changed」「New Features」「Improvements」「Bug Fixes」と
    コード一覧、前回バージョンとのDiff、ダウンロードリンクを含んだ情報をChangelogに反映する。
  • Changelogは英語版もあるため、「DeepL」を使って翻訳する。
    ダンおにや音ゲー特有の用語はそのままではうまく変換できない場合があるため、
    下記のページを参考に修正する。
    https://github.com/cwtickle/danoniplus-docs/issues/1

6. 関連ページの作成・修正(機能更新時)

  • 機能更新を伴う場合は、関連ページを作成・修正する。
  • 修正後、更新履歴があるページの場合は「対象のバージョン」と更新内容を記載する。
  • バージョン番号には履歴をつけており、日本語の場合はリリースノート、英語の場合はChangelogのリンクをつけている。(現状、リリースノートは日本語のみの対応のため)
|[v30.6.0](https://github.com/cwtickle/danoniplus/releases/tag/v30.6.0)|・ライブラリ用カスタムキー定義 (g_presetObj.keysDataLib)を追加|
|[v30.6.0](Changelog-latest#v3060-2023-03-18)|- Added custom key definitions for libraries (g_presetKeysData).|

7. ID一覧の修正(レイアウト変更時)

  • レイアウトの変更やIDの追加/変更があった場合、IDリファレンスを更新する。

8. 更新情報概要の修正(機能更新時)

  • リリースノートで「New Features」に記載した内容及び6. で更新したwikiのページへのリンクを張る。

9. リリースノートに更新したページのリンクを追加(機能更新時)

  • 4.で作成したリリースノートのDocumentationに、6.で追加したページのリンクを張る。

メジャーバージョンアップ時の対応事項

10. アップグレードガイドの作成

  • 過去バージョンからの非互換内容をアップグレードガイドへ記載する。
  • 通常、留意事項はあらかじめPull Requestなどで草案を書いておき、文書化する。
  • 「変更点」「変更時の対応事項」の順にリスト化して書く。
  • メジャーバージョンアップだけでなく、ひとつ前のバージョンで項目や変数が追加された場合には対象バージョンを記載してその内容を書く。
  • リリースノートのRemarksに記載があっても、それを毎回見るとは限らないため。

11. リリースノート(現行バージョン)のリンク先修正

  • リリースノート(現行バージョン)にはmasterブランチとの比較用にリンクが張られているが、メジャーバージョンが上がると過去バージョンになるため、比較対象がsupportブランチに変わる。
  • Chrome拡張: Find & Replace for Text Editing を使ってmastersupport/v30(ver30の場合)へ一斉置換する。
  • 同じく、Changelogのリンクも変わるためlatestv30(ver30の場合)に置換する。
  • これらを現行バージョンのリリースノートすべてに対して行う。

12. Changelog-latest のデータ移動

  • 最新のChangelogが古くなるため、(ver30の場合)Changelog-v30を作成しChangelog-latestから引っ越しを行う。
  • Chrome拡張: Find & Replace for Text Editing を使ってmastersupport/v30(ver30の場合)へ一斉置換する。
  • 同じく、Changelogのリンクも変わるためlatestv30(ver30の場合)に置換する。

13. Changelog-latest関連のリンク変更

  • Changelog-latestからChangelog-v30にリンク変更したため、他のwikiの全ページに対してリンク置換を行う。
  • なお、1つ1つに対してリンク変更するのは非常に手間のため、あらかじめwikiをgit cloneし、「Visual Studio Code」の「検索」から複数ファイルをまとめて置換する。
  • 置換対象が合っているかどうかを確認して、問題が無ければpushする。
  • 英語版も同様に修正する。こちらはChangelogの最新版をトップページとしてリンクしていることが多いため、注意が必要。

14. 更新終了バージョンの情報反映(Changelog)

  • 更新終了バージョンのChangelogに、更新が終了した旨の記載を追記する。

日本語

## [Warning] 更新終了後の不具合情報
- [更新を終了したバージョンの不具合情報#v28](DeprecatedVersionBugs#v28) を参照

英語

## [Warning] Defect information for unsupported versions
- See [Defect information for unsupported versions#v28](DeprecatedVersionBugs#v28).

15. 更新終了バージョンの情報反映(リリースノート)

  • 更新終了バージョンのリリースノートに、更新が終了した旨の記載を追記する。
  • 下記はver28の更新終了を表すアナウンス。
## ⚠️ Warning
- ver28の最終バージョンです。以後、不具合が発生しても修正は行われません。
後継バージョンの利用を推奨します。
⇒ [Security Policy (セキュリティポリシー)](https://github.com/cwtickle/danoniplus/security/policy)[サポートを終了したバージョンの不具合情報](https://github.com/cwtickle/danoniplus/wiki/DeprecatedVersionBugs#v28)
  • 通常、同一バージョンの最終版との比較リンクがついているが、不要のため外す。
( [vs. latest v28](https://github.com/cwtickle/danoniplus/compare/v28.6.7...master#files_bucket) )
( latest v28 )

16. 更新終了したバージョンの情報反映(更新終了バージョンの不具合情報)

日本語

## v28
- (現状なし)

英語

## v28
- (Nothing)

| < ライフサイクルポリシー | リリースまでの流れ || Ruffleの使い方 > |

English | Japanese

How To Play
(プレイ方法)

How To Make
(作り方、移行方法)

How To Upgrade? / What's New?
(本体の更新方法、更新情報)

Specification (for creators)
(仕様・製作者向け)

Specification (for developers)
(仕様・開発者向け)

Tips
(用途別対処方法)

Repository Local Rules
(リポジトリルール・管理者向け)

Others
(その他)

Clone this wiki locally