Q＆Aシステムに取り組んでいて、現在のアプリケーションに最初の公式バージョン/タグとして「1.0.0」のタグを付けようとしています。ベータテストのために、次に限定されたテスト対象者にロールアウトするところです。この段階で「1.0.0」は正しいですか？
また、その段階で多くのバグが見つかることは間違いありません。「1.0.0」のままにしておきますが、リリースされるまでタグを強制的に移動します。または、バグを修正したら、新しいタグ「1.0.1」を付けますか。その後、おそらく「1.0.2」のテストを繰り返します。
したがって、拡張機能（たとえば、新しいメニュー、新しい検索入力フィールドなどの新機能）に取り組む場合、これらは「1.0.0」から「1.1.0」へのように小さな変更でしょうか？
回答:
セマンティックバージョニングの使用を検討しているとのことですが、http：//semver.org/にあるセマンティックバージョニング仕様を見てみましょう。
バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。
- 互換性のないAPI変更を行った場合のメジャーバージョン
- 下位互換性のある方法で機能を追加する場合のマイナーバージョン
- 下位互換性のあるバグ修正を行う場合のパッチバージョン。
プレリリースおよびビルドメタデータの追加のラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。
そしてもう少し下：
プレリリースバージョンは、パッチバージョンの直後にハイフンと一連のドットで区切られた識別子を追加することによって示すことができます。識別子は、ASCII英数字とハイフン[0-9A-Za-z-]のみで構成する必要があります。識別子を空にすることはできません。数値識別子に先行ゼロを含めることはできません。プレリリースバージョンは、関連する通常バージョンよりも優先順位が低くなっています。プレリリースバージョンは、バージョンが不安定であり、関連する通常のバージョンで示されているように、意図した互換性要件を満たさない可能性があることを示します。例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
したがって、1.0リリースの真のベータ版をリリースする場合は、それにタグ付けする必要があります1.0.0-beta（または仕様に従って同様）。あなたがバグを修正するように、複数のベータリリースを持ってしようとしている場合は、1.0.0-beta.1、1.0.0-beta.2、など
下位互換性のある機能を追加する場合は、MINOR数を増やす必要があります。アプリケーションの他の場所で重大な変更を引き起こす内部変更を多数行った場合、それは大きな変更です。それほど劇的な変更を行わない場合（たとえば、コードを追加するだけで、既存のコードの動作は変更しない場合）、これはマイナーな変更になります。UIの多いアプリケーションがあり、そのUIを完全に変更する場合、それもメジャーな変更であると言えます（UIはエンドユーザーのAPIと見なすことができます）。
どのようにあなたのgitリポジトリに指標を追加するには、私はあなたが最初に作成することをお勧めしたい1.xブランチを。これにより、マスターでのバージョン2の継続的な開発を可能にしながら、バージョン1のすべてを簡単に追跡できます。次に、ベータリリースにタグを付けます1.0.0-beta（または-beta.1、複数のベータ版がある場合）。修正する必要があるすべてのバグを修正したら、実際の1.0.0リリースにタグを付けます。次に、必要に応じて各リリースにタグを付けます。
gitフローやgithubフローのようなgitの実証済みのワークフローを見て、継続的なワークフローをどのように設定したいかを考えてください。
また、APIなしのプログラムのセマンティックバージョニングについてもう少しコンテキストが必要な場合は、この答えは少し深く入ります。
はい、それがあなたの制御の外に移動し、他の誰かのものに移動するたびに、バージョン番号を更新します。
その理由は、彼らが何を使っていたかを知る必要があるからです。テストが戻って「バージョン1.0.0にバグが見つかりました」と言ったとき、最後に必要なのは「どのバージョン1.0.0か、月曜日に提供したバージョンか、金曜日に更新したバージョンですか？」 」
3番目の数値の更新はこれのために実際に設計されたものであり、1.0.0と1.0.999の間の機能的な違いは制限されるはずです。大きな新しい機能を追加する場合、2番目の数値を更新します。ただし、新しい検索入力フィールドを追加しても、2番目の数値の更新を保証するのに十分なほど大きな変更とは見なされませんが、YMMVです。
個人的には、機能の更新ではなく2番目の番号を使用する傾向がありますが、「完全なリリース」、つまりテストを通過して合格したものにマークを付けます。次に、その値を更新し、devとtestの間で往復を繰り返し、すべてがパスするまで3番目の数値を毎回増やします。
良い答えはすでに与えられていますが、アプリケーションにgit sha1を組み込む方法も見つけるので、この特定のリリースで使用されたのはgit commit 1b5619273127398123でした。そうすることで、BigCoのスミス氏が電話をかけ、アプリが正しく機能していないと不平を言うと、「2番目の文字列の数字と文字の長い列は何ですか？」と尋ね、git checkout NNNNNN正確にそれを得ることができます。次に、スミス氏と同じ手順を実行し、（うまくいけば）問題を再現します。微妙に異なるバージョンを使用しているために再現できない問題を見つけようとするよりも悪いことはありません（偶然にまたは意図的にその特定の問題を回避している場合）。
また、ビルドシステムがバージョンに含まれていることを確認してください-できればどのコンパイラバージョンなどを含めて-エンコードするか、gitリポジトリ内で製品をビルドするときに使用するビルドツールを保存します。