コンテキスト: セマンティックバージョニング について最近知り、自分のプロジェクトで実際に使用する方法を決定しようとしています。
Semverがバージョニングのためにメジャーな変更、マイナーな変更、パッチを考慮に入れている場合、コミットに更新されたバージョンのタグを付けないのはいつですか?すべての変更がこれらのカテゴリの1つに収まるように思えるので、すべての変更をバージョン管理する必要がありますが、GitHubでさまざまな人気のあるプロジェクトを見ると、これは物事が行われている方法ではないようです(単に大規模なプロジェクトには数万のコミットがあり、タグが数百しかないという事実があります)。
SemVerはバージョン管理releasesではなく、commitsではありません。バージョン管理モデルで、マスターへのすべてのコミットをリリースにする必要がある場合は、変更の程度に応じて、すべてのコミットにタグを付ける必要があります。
ただし、一般に、プロジェクトはmasterでほぼ安定した製品を開発し、サポートに値すると思われるリリースにタグを付けます。その場合、バージョンスキーマに従ってタグ付けします。これは特にSemVerである必要はありません。
バージョン番号はリリースに割り当てられます。一般に、すべてのコミットがリリースである必要はありません。これにはいくつかの理由があります。
最初に、すべてのコミットを「テストする」と言いながら、テストのレベルがあります。 1台のマシンで自動化されたテストスイートを実行することはすべて問題ありませんが、複雑なソフトウェアでは、すべての問題を解決できるとは限りません。一部の問題はハードウェアまたは構成に固有である可能性があり、一部の問題は、ハードテスト可能な要件よりも人間の主観的な考慮事項に関するものである可能性があります。
次に、メジャーバージョン番号を上げることはまれなアクションです。それは基本的に、ソフトウェアに依存するすべてのものを手動でチェックして、削除された機能に依存しているかどうかを確認する必要があることを意味します。
その結果、それらの機能を現在の形式で長期間サポートする準備ができている場合にのみ、フル(アルファ/ベータではない)リリースで「パブリックAPI」に機能を追加する必要があります。
第三に、広く使用されているバージョンの数を抑えることは有用です。安定したブランチであっても、多くの修正をまとめて1つのリリースを作成する方が、修正ごとにリリースを作成するよりも優れていることがよくあります。
言うまでもないようですが、バージョン番号の目的は、実行中のソフトウェアのバージョンを簡単に判別できるようにすることです。
コードの特定の反復にアクセスできる可能性があり、一意の識別子を簡単に特定できない場合、その反復には一意のバージョン番号が必要です。私はこれを「第一のルール」と見ています。その結果、リリースごとにバージョン番号が明確に必要になります。
ただし、さらに多くのことが関係します。
これを確認する1つの方法は、コミットごとにバージョン番号を増やすことですが、これは通常は良い考えではありません。比較的小さな変更が機能するようにするには、いくつかのコミット/反復が必要な場合があります。また、累積された多数の変更の結果として0.0.2-> 0.0の結果としてバージョン0.0.1-> 0.0.2が表示されると、外の世界が混乱します。 .56誰かがホワイトスペースをコミットし、一度に1つのファイルを修正し、機能を変更しなかったため。
「完全なリリースごとに1つのバージョン」から「コミットごとに1つのバージョン」までの道のりは、あなた、他のユーザー、そしてギャップを埋めるためにどのシステムを使用するかによって異なります。
私は個人的に小さなプロジェクトでの作業に慣れており、他の人が使用するバージョンとこれらのそれぞれのバンプバージョンまでgitハッシュを使用できます(手に入ると期待している人の数が少なくても)。ただし、大企業や大規模プロジェクトでは、セマンティックバージョン番号以外の何かが使用されますが、リリース候補の番号付けなど、各コミットよりも忠実度が低くなります。これらには利点がありますが、複雑さが増します。
マスターにマージされるすべてのプルリクエストはバージョン管理する必要があります。
それが新しいバージョン(少なくともパッチ)であってはならない場合は、機能/修正/その他が完全でないため、マスターにマージしてはいけません。
ただし、チームのワークフローによっては、バージョンなしでマスターするための複数のコミットが発生する可能性があります。押しつぶされないプルリクエストにいくつかのコミットがある場合(それらは私の意見ではないはずです)、まだ10のコミットと1つの新しいバージョンだけで終了する可能性があります。