APIを使用しないプログラムにセマンティックバージョニングを適用する方法

でhttp://semver.org/ -which私の認識では、ブレークは/ APIを変更し、その変更が導入されたときにメジャーバージョン番号を増やすことをお勧めしますversioning-で最も広く使用されている慣例のようです。

ただし、このガイドラインの適用方法がわからない2つの関連シナリオがあります。

1. コードがAPIを提供しない場合はどうなりますか？コードをバージョン管理するにはどうすればよいですか？
2. コードの開発後期にAPIの提供を開始したらどうなりますか？

Semverは、さまざまな形で依存関係の地獄を回避する方法で、ライブラリとパッケージをバージョン管理することを主に懸念しています。ただし、Semverの背後にある考え方は、あらゆる種類のプログラムに拡張できます。どのコードにも何らかの種類のユーザーインターフェイスが備わっているか、まったく役に立たないのです。

• プログラミングライブラリまたはWebサービスにはAPIがあります。
• 消費者向けソフトウェアにはGUIがある場合があります。
• コマンドラインプログラムには、一連のスイッチとオプションがあります。
• 構成ファイルはユーザーインターフェイスでもあります。

ワープロなどの消費者向けソフトウェアの例を使用します。

• バグ修正を出荷するときに、パッチ番号を増やします。例：「火曜日の午後00:00にアプリケーションが常にクラッシュするバグを修正しました」。
• 新しい機能を追加するとき、マイナーバージョン番号を増やします。たとえば、「下線付きテキストのサポートを追加しました」。
• ユーザーインターフェイスを大幅に見直した場合は、メジャーバージョンを増やすか、すべての内部を書き換えます。例：“ ツールバーは画面を使いすぎます。UIは現在、タッチジェスチャのみで提供されています '' –このような変更は、既存のワークフローを破壊します。

ただし、Semverが解決しようとする多くの問題は、依存関係管理の領域外には存在しません。コンシューマーアプリケーションでは、バージョンはバージョンだけでなく、マーケティング資産でもあります。

• FirefoxとChromeは新しいバージョンを比較的頻繁にリリースし、リリースごとにメジャーバージョン番号を増やします。これにより、とてつもなく高いバージョン番号が得られます（両方とも現在30代です）。高いバージョン番号のブラウザは、低いバージョン番号のブラウザよりも優れている必要がありますよね？

• AppleのオペレーティングシステムOS Xのメジャーバージョン番号が名前の一部になり（Xはローマ数字で10）、マイナーバージョン番号が有効なメジャーバージョン番号になりました。

• Ubuntuオペレーティングシステムは、year.month.patchlevelバージョン管理スキームを使用します。これにより、OSの古さを簡単に覚えることができますが、どのバージョンに互換性があるか、各バージョンのサポートがどれだけ続くかを把握することははるかに難しくなります。

• Linuxカーネルはバージョン番号を2.6.39から3.0.0に上げました。これは、39Linuxの20周年を記念して少し大きくなったためです。

• Donald Knuthの伝説的なTeX植字システムは、バージョン3の時点で、各リリースで別の数字を追加することでπに収束するバージョン番号3.14159265…を使用します。これは、システムが完璧に近づいていることを示しています。同様に、Metafontシステムはe：2.7182818…に収束します。

したがって、多くのアプリケーションはSemverによって十分に処理されません。ユーザーに適したバージョン管理スキームを選択し（これらのユーザーが仲間のプログラマーであるか消費者であるかに関係なく）、一貫性を保ちます。