web-dev-qa-db-ja.com

単純なバージョン番号からセマンティックバージョニングへの切り替え

現在「単純なバージョン番号」を使用しているソフトウェアライブラリ/アプリケーション/フレームワークがあります。したがって、現在（たとえば）バージョン135およびリリースは、「新しいリリースが十分にある」ときはいつでも不規則な間隔で作成されます。次のリリースは136このスキームでは。

これをセマンティックバージョニング（もちろん、バージョン番号およびリリース動作）を使用するように切り替えたいです。

「最初の」セマンティックバージョンにはどのバージョンを使用すればよいですか？

つまり、次のリリースが135.1.0 ...または136.0.0。または1.0.0？ 「正しい」アプローチとは何であり、どのアプローチが最も少ない数のバージョン比較アルゴリズムを壊しますか？

versioningrelease-managementsemantic-versioning
2
Daniel Jour

概念的には、既存のバージョン番号1、2、3、...、134、135をsemverバージョン1.0.0、2.0.0、3.0.0 ... 134.0.0、135.0.0として再相互運用することをお勧めします

次に、semverのルールに従って、次のリリースに番号を付ける方法を決定します-重大な変更がある場合は136.0.0、新しい機能が含まれる場合は135.1.0、バグ修正以外の変更がない場合は135.0.1 。

3
bdsl

開始する番号を選択することは、セマンティックバージョニングに切り替える最も簡単な部分です。セマンティックバージョン番号を維持することは、大きな投資です。単純なバージョン管理では、アップグレードによって重大な変更がもたらされないという約束はありません。セマンティックバージョニングは、重大な変更を行わずにマイナーバージョンをアップグレードできることを意味します。これは、マイナーリリースの対象となる新機能を決定するために労力を費やす必要があることを意味します。これは必ずしも簡単ではありません。また、2.0をリリースし、1.5にも影響する重大なセキュリティの脆弱性が見つかった場合、両方のバージョンにパッチを適用する予定である場合は、短期間に複数バージョンのコードのサポートを開始する必要がある場合もあります。古いバージョンをサポートしない場合、アップグレードパスは次のメジャーバージョンのみなので、切り替えの意味はあまりありません。独自の依存関係をアップグレードするとどうなりますか？それはマイナーバージョンだけですか？セマンティックバージョニングは有益なものになるでしょうか。2年後には、バージョンはx.0.0からx + 5.0.0またはx.20.0に移行しますか？バージョン番号の1つの部分だけが増加することになっても、いずれにしても単純なバージョン管理と変わりません。

セマンティックバージョンを使用することにはコストがかかります。そのコストを正当化するのに十分な利益が実際に得られていることを確認する必要があります。自分がそうであると感じた場合は、開始して136.0.0が最も簡単な解決策です。1.0.0にリセットする場合は、名前を変更するか、変更を明確にするのに役立ちます。

2
Ryathal

SemVerは パブリックAPIに対して定義 のみです。開発でそのようなAPIが定義されていない場合は、まずSemVerを解釈して、その使用を パブリックAPIのないソフトウェア または 他の形式のコンテンツ であると明確にする必要があります。

1.0.0からのバージョン管理を再起動しない必要があります。

  • 実用上の理由から、バージョン1、10、および100との混乱のリスクを回避するため。
  • 正式な理由により、 SemVer-clause 4 は不安定なパブリックAPIの開発段階用にメジャーバージョン0を予約し、 SemVer-clause 5 は初期バージョン用にバージョン1.0.0を予約するため安定したパブリックAPIの定義。あなたの言い回しを考慮して、次のバージョンはAPIを定義する最初の公式バージョンではないことを理解しています。したがって、1.0.0は準拠しません。

過去の各リリースを厳密に逆解析して、実際のSemVerバージョンを決定するという厳密なアプローチは避けてください。実用的な理由から：非常に時間がかかり、なぜバージョン136からバージョン12.4.5に切り替えたのかという話はあまり興味深いものではありません。

最も賢明なのは136.0.0から始めることです。新たなスタートです。誰もが理解できるようになり、バージョン履歴は上向きになります。あなたの製品がすでにある場合、これをお勧めします かなり古い 非常に成熟している場合（例：平均月間リリース）、または顧客からの不要な質問に答えたくない場合。

製品がまだかなり新しい場合（たとえば、過去の平均で毎週のリリースなど）。バージョン2.0.0から開始できる可能性があります。これは、ドットバージョン管理スキームを採用し、古いバージョンを1.3.5と見なし、次のメジャーバージョン（バージョン管理ロジックをすべて変更した後）が2.0.0であると述べることで正当化できます。

現在、商用ソフトウェアを使用している場合、実用的でよく使用される市場志向のアプローチは、最大の競合他社よりも2つのメジャーバージョンを先行させることです。あなたの顧客はあなたの製品が最も進んだものであることを理解するでしょう。しかし、ソフトウェアエンジニアとして、説明を見つけようとしないでください。マーケティング部門に最も説得力のある説明を選択させてください;-)/*言うまでもありません。この最後のアプローチを客観的に推奨することはできません* /

2
Christophe