ゲームバージョンのラベル付けのベストプラクティスですか？

ゲームのバージョンにラベルを付けるためのベストプラクティスがあるかどうかは誰でも知っていますか。

バージョン管理以外の標準的な名前があるかどうかはわかりませんが、基本的には次のとおりです。

• 1.0
• 1.1
• 1.2
• 1.3.1ベータ

標準はありませんが、あなたにとって意味のある方法で行う必要があり、そのビルドを追跡するために必要なすべての情報が含まれています。私は本質的にこのようにそれを分解した会社で働いていました：

[メジャービルド番号]。[マイナービルド番号]。[リビジョン]。[パッケージ]

すなわちバージョン：1.0.15.2

• メジャービルド番号：これはゲームの主要なマイルストーンを示し、ベータからリリース、リリースからメジャーアップデートに移行するときにこれを増やします。

• マイナービルド番号：機能の更新、大きなバグ修正などに使用されます。

• 改訂：既存の機能の小さな変更、小さなバグ修正など

• パッケージ：コードは同じままで、外部ライブラリの変更またはアセットファイルの更新。

結合された変更は、最も重要な変更にロールオーバーします。たとえば、マイナービルド番号を増やしている場合、リビジョンとパッケージは両方とも0にリセットされます。

カテゴリが定義されていても、リビジョンとマイナービルド番号の間で実際にどのような機能が交差するかについては、まだあいまいさがあります。それはあなた次第です。各インクリメントの前に実装する必要のある機能のリストを作成する場合、従う計画もありますが、最終的には、各カテゴリに適合するものを決定します。

Stack Overflowには、「バージョン管理スタイルガイド」を参照する「How To Do Version Numbers」と呼ばれるこれに関する優れた議論があります。

概要：

• 互換性のないAPIを変更した場合のメジャーバージョン
• 下位互換性のある方法で機能を追加する場合のマイナーバージョン
• 後方互換性のあるバグ修正を行うときのパッチバージョン
• プレリリースおよびビルドメタデータの追加ラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます

私の知る限り、そのための標準はありません。プラクティスは、企業、チーム、プロジェクトによって異なります。ベストプラクティスなどはありません。最も重要なことは、実際の慣習ではなく、誰もがそれに固執しているという事実です。

とはいえ、あなたが言及したスキームはリリースされたゲームでは非常に一般的です。1.0は通常ゴールドマスターであり、パッチはそこから始まります：1.1、1.2 ...また、プライベートベータまたはオープンベータなどのプレリリース版の顧客バージョンでも使用されます。

開発中のゲームでは、このシステムが使用されることはめったにありません。アトミック変更ID（Perforceチェンジリスト番号など）でビルドを参照するのがはるかに一般的です。これは、すべて（コードとアセット）が同じリポジトリに保存され、継続的な統合が行われている中規模プロジェクトで特に役立ちます。この場合、アトミック変更番号とバージョン番号の両方を持つことは冗長であり、エラーが発生しやすくなります。一部のビルドは、QA後のマイルストーンに昇格します：アルファ、ベータ、リリース候補、およびそのようなラベル。

大きなプロジェクトの場合、「ゲームバージョン」という単純な概念はもう適用されません。複数のプラットフォーム、SKU、言語、シングルプレイヤーモード、マルチプレイヤーモードなどがあります。バージョンの管理はフルタイムの仕事になります（データマネージャーとも呼ばれます -これはUbisoftの用語で、おそらく別の場所で呼ばれます）。 、ラベリングスキームははるかに複雑であり、作成される実際のゲームに大きく依存します。