web-dev-qa-db-ja.com

安定バージョンと不安定バージョンの間でバグが修正された場合のセマンティックバージョンでのバージョン管理方法

セマンティックバージョニングに疑問があります。 semver に示されているようなセマンティックバージョンを使用しています

このシナリオを想像してください：

  • 1.1.0という名前の安定版
  • 1.1.1-rc1という名前の不安定なバージョン
  • 安定バージョン1.1.0でバグが発見されました。できるだけ早く修正する必要があります
  • 1.1.1-rc1バージョンはテスト環境にデプロイされていますが、まだ検証されていません

では、バグを解決するバージョンは何でしょうか？つまり、1.1.1-rc1の名前を1.1.2-rc1に変更し、1.1.1のバグを解決することは良い習慣ですか？

または別のアプローチが必要ですか？

versioningsemantic-versioning
3
Miguel Ángel García Gómez

semVer仕様から https://semver.org/

プレリリースバージョンは、パッチバージョンの直後にハイフンと一連のドットで区切られた識別子を追加することで示すことができます。

...プレリリースバージョンは、関連する通常バージョンよりも優先順位が低くなっています

...メジャーバージョン、マイナーバージョン、およびパッチバージョンが同じである2つのプレリリースバージョンの優先順位は、相違点が見つかるまで、ドットで区切られた各識別子を左から右に比較して決定する必要があります。

だからあなたは1.1.1-rc1と1.1.1-rc2を持つことができるようです

正直なところ、このプレリリース版はバージョン管理とテストのあざけりになると思います。バグを修正する場合は、1.1.1をリリースするかリリースせず、1.1.2を使用してください。

サポートされているバージョンが複数ある場合は、それらが異なるメジャーバージョンであることを確認してください。そうでない場合、4番目のバージョン番号が必要になります。

-編集、

質問は私の回答以来少し編集されていると思います。

re：1.1.1-rc1がすでにパイプラインにあるが、すぐにはリリースされない場合、v1.1.0 +緊急のバグ修正を何と呼ぶべきですか？

さて、すべてのバージョンをリリースしなければならないというルールはありません。1.1.1はテストに失敗しました。この緊急のバグについて知っているからです。 「v1.1.0 +緊急のバグ修正」を1.1.2-rc1としてリリースし、通常の手順に従って1.1.2としてリリースします。

私はあなたの反対が「1.1.1が新しい機能を持っていることについて話しているので、機能なしで1.1.2をリリースすることは顧客を混乱させ、このバグを見逃したことを明らかにします！」

私が言うには、その新機能の場合、2.0.0ではなくても少なくとも1.2.0でなければなりません！ 3桁目はパッチであり、機能ではありません。 1.2.0、1.2.1などとして機能を実行し、1.1.3、1.1.4などの機能なしで「緊急」修正を続行できます。

メジャー番号を更新しないように契約上義務付けられている会社があることは知っています。同様の状況にある場合、おそらく4番目のバージョン番号を追加して1.1.1.2を取得する必要がありますか？

異なるビルドを正しく示すためにバージョン番号を更新することに不安がある状況に陥らないでください。誰かが誤ってリリースしたバージョン1.1.1をどこかに持っていて、1.1.1ではなく1.1.2が必要な場合（修正済み、誰にも気付かれないように！

4
Ewan

パッチのテストと展開は比較的簡単なはずです。重要なバグ修正を含む1.1.1-rc2を作成し、リリースプロセスごとに完全にテストし、できるだけ早く1.1.1をリリースして、1.1.1で変更を加えることをお勧めします。 1.1.1でさらに多くのバグ修正を計画していたかもしれませんが、重大なバグがある場合は、1.1.1をより早く入手し、残りのバグ修正を1.1.2または1.2.0リリースに入れる価値があるかもしれません。バグ修正のみ、または下位互換性のある新機能も含まれます。

1
Thomas Owens

これは、SemVerバージョン管理スキームに完全に適合するアプローチです。

  • テスターがテスト中にこれを発見したかのように、1.1.0から1.1.1-rc1への変更セットが予期しない問題を引き起こしたとしばらく考えてください（これが本当に本当でなくても、あたかもそうであるかのように動作します）

  • したがって、1.1.0から1.1.1-rc1へのすべての変更をロールバックします（つまり、安定したベースライン "1.1.0"から再び開始します）。このコードには、必要に応じてバージョン番号「1.1.1」を付けることができます（バージョン番号が実質的に1.1.0と同じで、バージョン番号が変更されているだけなので安定しているので、「rc」ラベルは不要です。 ）。次に、緊急のバグ修正のみを追加します（通常のQAをバイパスするのが非常に緊急である可能性があります。少なくとも、「rc」ラベルなしで他の何よりも先にテストされます）。 SemVerによると、これによりバージョン「1.1.2」が生成され、本番環境に迅速にデプロイされます。

  • 次に、元のパッチセットを「1.1.0〜1.1.1-rc1」から「1.1.2」に再導入します。 SemVerによると、これは「1.1.3」になります。必要に応じて「-rc1」を再度追加し、テスト環境に展開します。

したがって、結果のバージョンのシーケンスは、単なる線形シーケンスです

    1.1.0          stable baseline
    1.1.1-rc1      unstable test version, containing a changeset A
    1.1.1          stable version, but A reverted (so identical with 1.1.0)
    1.1.2          stable version, including only urgent fix B, but not A
    1.1.3-rc1      unstable test version, containing A and B

これはSemVerのすべてのルールに従い、既存のバージョンを「名前変更」または「ラベル変更」する必要はありません。中間バージョン「1.1.1」は、緊急のバグ修正を組み込んだ開発者のワークステーションで、1分間（またはそれ以下）の作業用コピーとしてのみ、非常に短い期間しか存続しません。

1
Doc Brown