今日、私の同僚の 1 人が、一部のプロジェクトでは、リリースのバージョン管理に奇妙で私見のような方法を使用していることを教えてくれました。リリースが不安定な場合、マイナー バージョンは奇数です。1.3、1.5。一方、安定版リリースにはさらにマイナーなバージョン番号があります。1.2、1.4。
最初は自分の耳が信じられませんでした。その後、ウィキペディアは、最近削除されたように(?) 見えますが、これは Linux カーネル コミュニティからの慣習であると教えてくれました。
数時間後、プログラミング Ruby の序文を読んでいますが、何が表示されますか? Ruby はバージョン番号に同じ規則を使用します。
これについてあなたの経験は何ですか？このバージョニング スキーマを使用している、あなたが知っている (オープンソースの) プロジェクト/製品は何ですか? 彼らがこの規則に従っている場合、すぐに理解する簡単な方法はありますか? そんなに人気あるの？私は 3 年と少し前にソフトウェア開発を始めましたが、この慣行について聞いたことがありません。
ご回答ありがとうございます。
Linux カーネルは、2003 年の 2.6 カーネルの開始とともにその慣行を廃止しました (つまり、2.4 は、対応する 2.5 開発ブランチを持つ最後の安定版でした)。私は、プロジェクト全般に関する修士論文に書いたことを調べました。
安定版ブランチと開発版ブランチの分割は、オープン ソース プロジェクトでは非常に一般的な戦略ですが、より多くのブランチを使用するものもあります{footnote}。使用されるリリース番号は、しばしば abc の形式で奇数/偶数スキームを使用します。ここで、a はメジャー リリース番号、b は安定版の場合は偶数、開発版の場合は奇数、c は一連のリリース番号です (追加の d も使用される場合があります)。 ）。
{脚注} たとえば、XEmacs の開発は、安定版、ガンマ版、ベータ版の 3 つのブランチに分かれています。Debian では、experimental、unstable、testing、stable を使用しています。
Linux カーネルの詳細については、「2.2.4 Linux 開発ブランチ」の章全体を自由に読んでください。
編集:元のリンクはなくなりました。ここに新しいリンクと適切な引用があります:
Løvdal、H.（2006）。オープン ソース管理者プロジェクトの分析と説明 (修士論文、Høgskolen i Agder)。
GTK+とGNOMEもそのバージョン管理スキームを使用します。1.9（安定している）以降、rubyはこのスキームを使用しなくなったことに注意してください。
多くのオープンソース プロジェクトはこれを使用しましたが、ほとんどは他の方法に変更されました。たとえば、Linux カーネルはこれを行っていました (かなり前)。最近、Mesa (Linux 用のオープン ソース OpenGL スタック) は、バージョン 2.5 でこの方法の使用を停止しました。
私見、すべてのリリースは比較的安定している必要があります。まだ安定していない場合は、アルファまたはベータ リリースにする必要があります。たとえば、KDE 4.0 のリリースはひどい間違いでした。4.0 はアルファ版である必要がありました。4.1 はベータ版である必要がありました。4.2 は、実際に使用できる最初のリリースでした。