ゲームのversioningルール検討メモ
ゲームのリリースに無意識の内にsemantic versioningをつけていたが、とりあえずゲームにsemantic versioningは相性が悪いのでなんとかしたいという事で、色々と検討した内容をメモしておく
最初に結論
- microsoft風がよいのでは、という結論になった。実際にある程度これで運用してみて、本当によいかどうか確認してみる
(major部はリリース毎に1ずつ増えるやつ).(minor部はリリース日時).(patch部はリリース毎のビルド番号もしくは一日に二回以上更新があった時に1ずつ増やすやつ)
検討内容メモ
そもそもの問題は、ゲームのリリース/アップデートに対するsemantic versioningが誰の役にも立ってないのをなんとかしたい
- 例えばnpmに置くようなライブラリであればsemantic versioningに応じて「とりあえず最新版」とか「最新版は特定機能にバグがあったから一つ前のmajorでの最新版にしよう」みたいな判断ができるので、semantic versioningする事に意味がある。しかしゲームの場合、プレイヤーが気にするのは「最新版になっているか、なっていないか(もしくはそれすら気にしないか)」だけなのでsemantic versioningする意味がない。一応「過去の特定バージョンをプレイしたい」というケースはあるもののその際の判定基準にsemantic versioningされた値を参考にするという事もまずない。
- 「このバージョン以降のゲームのセーブデータ/クラサバ間通信プロトコルは、それ以前のバージョンのゲームでは読み込めません」というケースはあり、これ自体はsemantic versioning(もしくはそれに類似するもの)にする価値があるものの、これはゲーム本体リリースのバージョンに含めるべきではなく、セーブデータもしくは通信プロトコル内自体に埋め込むと共にChangeLogあたりに「バージョンX以降のセーブデータをバージョンX以前のゲームで読み込む事はできません」「通信プロトコルFOO/1.2に対応し、FOO/1.0での通信は廃止」みたいな感じで書いておくべきものだ、という考え。
- 開発者的には、bisectとかしたい場合はsemantic versioningを見るのではなくgitとかの機能に頼るので、結局やはりsemantic versioningは役に立ってない感がある。
- ゲームではなくライブラリ系なら「バージョン8系で行った修正を7系にもbackportする」みたいなケースがありえるので有用だが、ゲームでそういう運用をするのはよほどの大型プロジェクトなのではという気がする。
ではsemantic versioningをやめて、どういうversioningルールにするのか
