APIなしのプログラムにセマンティックバージョニングをどのように適用するか
http://semver.org/ -これは私の認識ではバージョン管理で最も広く使用されている規則のようです-APIに違反/変更を加える変更がある場合は、メジャーバージョン番号を増やすことをお勧めします紹介します。
ただし、このガイドラインの適用方法がわからない2つの関連シナリオがあります。
- コードがAPIを提供しない場合はどうなりますか？コードをバージョン管理するにはどうすればよいですか？
- 私のコードが開発の後半の段階でAPIの提供を開始した場合はどうなりますか？
Semverは、さまざまな具体化で、依存関係の地獄を回避する方法でライブラリとパッケージをバージョン管理することに主に関心があります。ただし、Semverの背後にあるアイデアは、あらゆる種類のプログラムに拡張できます。コードのどの部分にも、ある種のユーザーインターフェイスがあるか、まったく役に立たないものです。
- プログラミングライブラリまたはWebサービスにはAPIがあります。
- 消費者向けソフトウェアにはGUIがあるかもしれません。
- コマンドラインプログラムには、一連のスイッチとオプションがあります。
- 構成ファイルもユーザーインターフェイスです。
ワードプロセッサなどのコンシューマソフトウェアの例を使用します。
- たとえば、「アプリケーションが常に00:00にクラッシュする修正済みのバグPM」のように、バグ修正を出荷するときにパッチ番号を増やします。
- 新しい機能を追加するときに、マイナーバージョン番号をインクリメントします（例：「下線付きテキストのサポートを追加」）。
- ユーザーインターフェイスを大幅にオーバーホールするか、すべての内部を書き直す場合は、メジャーバージョンを増やします。例：「ツールバーは画面領域を使いすぎています。UIはタッチジェスチャーのみで提供されるようになりました」–このような変更は既存のワークフローを壊します。
ただし、Semverが解決しようとする多くの問題は、依存関係管理の領域外には存在しません。コンシューマーアプリケーションでは、バージョンはバージョンであるだけでなく、マーケティング資産でもあります。
FirefoxとChromeは、比較的頻繁に新しいバージョンをリリースし、各リリースでメジャーバージョン番号を増やします。これにより、バージョン番号が途方もなく高くなります（現在両方とも30代です）。より高いバージョンのブラウザ番号は、バージョン番号の小さいブラウザよりも優れているに違いありませんよね？
Appleのオペレーティングシステムのメジャーバージョン番号OS Xが名前の一部になり（Xはローマ数字で10）、マイナーバージョン番号が有効なメジャーバージョン番号になりました。
Ubuntuオペレーティングシステムはyear.month.patchlevelバージョン管理スキームを使用します。これにより、OSの古さを簡単に覚えることができますが、互換性のあるバージョンや、各バージョンのサポートの継続期間を把握するのがはるかに難しくなります。
Linuxカーネルは、
39が少し大きくなり、Linuxの20周年を記念して、バージョン番号を2.6.39から3.0.0に上げました。Donald Knuthの伝説的なTeX組版システムは、バージョン3の時点で、リリースごとに別の数字を追加することでπに収束するバージョン番号3.14159265…を使用しています。これは、システムが完璧に近づいていることを示しています。同様に、Metafontシステムはe：2.7182818…に収束します。
したがって、多くのアプリケーションはSemverによって十分に提供されていません。ユーザーに適したバージョン管理スキームを選択し（これらのユーザーが他のプログラマーであるかコンシューマーであるかに関係なく）、一貫性を保ちます。