セマンティックバージョニングのガイド
1. 序章
SemVer は、バージョンリリースに含まれる変更を伝達するために、膨大な量のオープンソースプロジェクトで使用される人気のあるバージョン管理スキームです。 開発者として、私たち自身のプロジェクトでSemVerを使用する方法と、特定のバージョン変更を解釈する方法を理解することが重要です。
このチュートリアルでは、SemVer仕様の主な概念についてのガイドを提供します。
2. ソフトウェアのバージョン管理が重要なのはなぜですか？
ソフトウェアのバージョン管理は、ソフトウェアまたはパッケージが入っている状態を一意の名前や番号で識別するのに役立ちます。 バージョンは、開発者が使用しているサードパーティのソフトウェアまたはパッケージへの変更を追跡するのに役立ちます。
バージョニングスキームにはさまざまな種類がありますが、人気のあるものの1つは、バージョン番号の制御方法を指定するためにTomPreston-Wernerによって2013年に提案されたSemantic Versioning（SemVer）と呼ばれるスキームです。
3. SemVerとは何ですか？
SemVerバージョン管理スキームでは、バージョン管理は次の形式になります。
ここで、x、y、およびzは、数値的に増加し、それぞれメジャー、マイナー、およびパッチを示す整数です。
SemVer仕様では、このスキームMustを使用するプロジェクトにパブリックAPIがあることを前提としています。 これを踏まえて、左から右に向かって各部分を詳しく見ていきましょう。
3.1. 選考科目
APIを壊す新しい機能を導入した場合、つまり、プロジェクトに下位互換性のない変更を追加した場合は、この値を増やすと、メジャーバージョンが増えるはずです。この数を増やすときは、マイナー番号とパッチ番号を0にリセットします。
たとえば、バージョン 1.2.5 のプロジェクトがあり、SemVerスキームで重大な変更を導入した場合、新しいバージョン番号を2.0.0に設定する必要があります。 。
3.2. マイナー
APIを変更するが下位互換性のある新機能、つまり重大な変更を導入した場合は、マイナーバージョンを増やす必要があります。マイナーバージョンを変更した場合は、マイナーバージョンを変更することもできます。プロジェクトの内部コードに大幅な変更を加えました。
同様に、マイナーバージョンを変更する場合は、パッチバージョンも0にリセットする必要があります。 たとえば、プロジェクトのマイナーバージョンを 2.0.1 で更新すると、2.1.0に設定されます。
3.3. パッチ
SemVer仕様では、下位互換性のあるバグ修正のためにパッチの変更を予約しています。パッチの変更には、APIへの変更は含まれません。
3.4. プレリリースとビルド
パッチバージョンの後に、プレリリースラベルやビルド番号など、バージョンに追加できるオプションのラベルがいくつかあります。
たとえば、パッケージをプレリリースとしてマークするには、ハイフンを追加してからプレリリースラベルを追加する必要があります。これは、ドットで区切った識別子にすることができます。たとえば、1.0.0-alpha.1はこのプロジェクトは、alpha.1というラベルの付いた1.0.0のプレリリースバージョンです。 プレリリースラベルは、このバージョンが不安定であり、使用するとリスクが高いことを示しています。 バージョンの優先順位を検討する場合、プレリリースバージョンは常に通常のバージョンよりも優先順位が低くなります。
そのリリースのビルドを示したい場合は、パッチ（またはプレリリース）の後に+記号を付けて追加されたビルドのドット区切りの識別子を追加できます。 たとえば、 1.0.0-alpha.1 +001です。 ビルドメタデータは優先順位を考慮しないため、ビルド番号のみが異なる2つのバージョンは同じ優先順位であると見なすことができます。
4. 開発SemVer
SemVer仕様は、開発目的でメジャーバージョン0.xyを予約しています。 新しいプロジェクトを開始するときは、リリース 0.1.0 で初期開発を開始するのが理にかなっています。もちろん、機能が含まれているからです。 SemVerは、開発バージョンが不安定であり、いつでも変更される可能性があると想定しています。
5. なぜSemVerはとても人気があるのですか？
SemVerはここ数年で人気を博しています。 理由は次のとおりです。
- 従うのはかなり単純なスキームであり、変更を追跡することができます
- バージョンを比較することで、どのような変更が発生したかをすぐに知ることができます。 それが重大な変更であるか非重大な変更であるか
- パッケージの更新に伴うリスクは、メジャー、マイナー、またはパッチの変更であるかどうかを確認することですぐにわかります。 コードがまだ実行されていることを常に確認する必要がありますが、パッチを変更するだけでパッケージを更新すれば、現在の実装が損なわれることはないとかなり確信できます。 つまり、パッケージのプロバイダーもSemVerの使用に熱心に取り組んでいる場合です。
- SemVerは、開発者が依存関係地獄として知られているものを回避するのに役立ちます。 依存関係地獄は、他の依存関係の異なるバージョンを共有する依存関係がある場合に発生します。 SemVerは、開発者がこれらの競合を解決するのに役立つバージョン管理の明確な方法を提供します。 通常、これを行うには、使用できる許容可能なバージョンの範囲を指定します。 これは、プロジェクトにJavaScriptの依存関係をインストールするために、npmによって自動化された方法で頻繁に使用されます
6. その他のバージョン管理スキーム
使用されている多くの異なるバージョン管理スキームがあります。 これらのいくつかを簡単に見てみましょう：
- CalVer –このスキームはリリースの日付に依存します。 SemVerスキームほど具体的ではありませんが、PythonパッケージマネージャーPipやUbuntuなどのプロジェクトで使用されます。
- Pythonバージョン管理スキーム–Pythonのディストリビューションを識別するために定義されたスキーム。 このスキームは、エポック、リリース、プレリリース、ポストリリース、および開発と呼ばれる5つのセグメントを使用します
- 名前付きバージョン–一部のプロジェクトでは、リリースに一意の名前を付けることを選択します。 たとえば、Androidには、Cupcake、Donut、Eclairで始まった興味深いバージョン名のコレクションがあります。 必要に応じてAndroidリリースの完全なリストを見ることができます
- Springプロジェクトバージョンの命名–これはSpringFrameworkおよびSprintBootプロジェクトで一般的な方法であり、リリース候補のRCや開発リリースのBUILD-SNAPSHOTなどのいくつかの追加ラベルを使用してSemVerで拡張されます
7. 結論
SemVerはバージョン管理の唯一の方法ではありませんが、特にオープンソースプロジェクトの間で人気があります。
このチュートリアルでは、SemVer仕様を使用および解釈するためのクイックガイドを提供しました。 SemVerは、意味のある方法でパッケージをバージョン管理する方法を指定するソフトウェアバージョン管理スキームです。
