従来のセマンティックバージョニングスキーム「MAJOR.MINOR.PATCH」が意味をなすかどうかは、誰にデプロイするか、特にエンドユーザーにいつどのくらいの頻度でデプロイするかに依存します。このスキームは、4.5.0で始まる安定版リリース「4.5」で作業する場合に最も役立ちます。バージョン4.5.1、4.5.2などにはバグ修正のみが含まれていますが、内部ではすでにバージョン4.6で作業しています。
たとえば、エンドユーザーに「安定したブランチ」を提供する場合、初期デプロイメントにはバージョン4.5.0を、パッチをリリースするときは常に4.5.1、4.5.2を提供します。内部の「アジャイル」開発とミッドスプリントの展開では、すでにバージョン4.6を使用できます。これを「ベータ版」と呼んでください。スプリントの途中でデプロイする場合は常に、「4.6.beta build 123」のような自動生成されたビルド番号を追加します。スプリントが終了したら、「4.6.0」を割り当て、次のスプリントのバージョン番号を内部で「4.7」に切り替えます。「.0」で始まるのは慣例にすぎません。ベータ版のタグ付けに「.0」を使用し、エンドユーザーの場合は「.1」で始めることもできます。私見の「ベータ版」という言葉ははるかに表現力豊かで、スプリントは「まだ完了していない」と皆に伝えています。
ベータ版ごとに完全なエンドユーザー変更ログをリリースする場合、少なくともスプリントの最後に変更ログを完了し、エンドユーザーにバグ修正を提供するたびに更新する必要があります。履歴ドキュメント。
Inkscape、Firefox、7-zipなどの多くのオープンソース製品では、2つの独立したブランチ、1つはセマンティックバージョン番号のある「安定した」ブランチ、もう1つはビルド番号などのマークが付いた「開発ブランチ」をリリースする戦略が見つかります。
ただし、stableブランチと開発ブランチを別々に使用せず、新しいバージョンをエンドユーザーに毎日リリースする場合は、バージョン番号も毎日増やす必要があります。そのような場合、バージョン番号「4.5.1」、「4.5.2」、...はおそらく個々のデプロイメントを反映し、バグ修正と他の変更との違いを示しません。それは大丈夫かもしれません、それはもはや古典的な「セマンティックバージョン管理」ではありません。このシナリオでは、バージョン4.5、4.6、4.7、4.8をデプロイすることもできますが、実際の違いはありません。
変更ログのエントリに関する質問:エンドユーザーに何かが見える場合のIMHO変更をデプロイするとすぐに、変更ログにエントリする価値があります。たとえば、機能トグルを使用して、ユーザーに対してまだアクティブ化されていないハーフベイク機能に変更を加えた場合、変更ログには含まれません。ユーザーに目に見える変更がなく、リファクタリングのみを行う場合、それは変更ログには含まれません。一部のユーザーに影響を与える可能性のあるバグを修正する場合、それは間違いなく変更ログに属します-バグ修正をデプロイするときに、同時にそこに記載する必要があります。そして、あなたが毎日、毎月、または毎年リリースするかどうかは関係ありません。