依存ソフトウェアコンポーネントのバージョン番号付けのベストプラクティスを探している

相互に依存しているソフトウェアコンポーネントのバージョン番号付けを行うための適切な方法を決定しようとしています。

もっと具体的に見てみましょう：

ソフトウェアコンポーネントAは組み込みデバイスで実行されるファームウェアであり、コンポーネントBは通常のPC（Linux / Windowsマシン）用のそれぞれのドライバーです。これらは、カスタムプロトコルを使用して互いに通信しています。当社の製品は開発者も対象としているため、両方のコンポーネントの安定版と不安定版（実験版）を提供します（ファームウェアはクローズドソースで、ドライバーはオープンソースです）。私たちの最大の困難は、通信プロトコルでAPIの変更を処理する方法です。

ドライバーに互換性チェックを実装している間（ファームウェアバージョンがドライバーのバージョンと互換性があるかどうかをチェックします）、バージョン番号付けの複数の方法について議論し始めました。

私たちは1つの解決策を思いつきましたが、車輪を再発明したいとも感じました。これがプログラマー/ソフトウェア開発者コミュニティーからフィードバックを得たい理由です。これはよくある問題だと私たちは考えているからです。

だからここに私たちのソリューションがあります：

広く使用されているmajor.minor.patchをフォローする予定ですバージョン番号、安定/不安定バージョンには偶数/奇数のマイナー番号を使用するです。APIに変更を導入する場合、マイナー番号を増やします。

この規則は、次の状況例につながります。

現在の安定版ブランチは1.2.1で、不安定版は1.3.7です。現在、unstableの新しいパッチによりAPIが変更され、新しい不安定なバージョン番号が1.5.0になります。不安定なブランチは安定していると見なされます。たとえば、1.5.3では、1.4.0としてリリースします。

以下の関連する質問のいずれかに対する回答があればうれしいです。

• 上記の問題を処理するためのベストプラクティスを提案できますか？
• 私たちの「カスタム」慣習は良いと思いますか？
• 説明されている規則にどのような変更を適用しますか？

私見のバージョン番号は製品名のようなものです。それらは目に見えるという点で重要ですが、コンテンツではなく装飾であるという点では重要ではありません。

それでも、製品名のようなバージョン番号には意味があります。そして、あなたができる最も重要なことは混乱を避けることです。ここにいくつかの一般的な期待がありますため、バージョン番号に関するを次に示します。これらの例外が満たされない限り、ユーザーはおそらく混乱するでしょう：

バージョン番号は単調に増加しています
これはおそらく最も明白な期待であり、同時に実際に本当である可能性は最も低いです。一見すると、ユーザーはバージョン2.3.5がバージョン2.2.17の後に来て、同じまたはより優れた技術を持っていると期待しています。しかし、もちろん2.3.xは開発ブランチであり、2.2.xは安定しており、2.3.5は実際に2004年にリリースされ、2.2ブランチは現在も作業中です。2.2.17は昨年4月にリリースされ、含まれています。 ..まあ、あなたはアイデアを得る。同様に、バージョン2.2を「ポテト」と呼ぶだけでも、その番号が意味するすべての意味を知ることができます。バージョン「ポテト-17」へようこそ!!

同様のバージョンはアップグレード可能/互換性があり
ますコンピューターにバージョン3.7があり、3.8がすべての新しい光沢のあるfrozbotでリリースされた場合、アップグレードまたはパッチなどがあれば、3.7は中断なく3.8になります。しかし、私が3.7を使用していて、あなたが5.2をリリースした場合、私はそれほど楽観的ではありません。もちろん、失望するのではなく、うれしい驚きがあります。

最初の数字は重要
です。Javaが問題についてそれほど目立たないのであれば、私はこれについて言及することすらしません。誰かから言わない限り、「Java 7」が実際にバージョン1.7であるとは思わないでしょう。そして、これを初めて聞いたとき、あなたの反応はほぼ間違いなく「何？..なぜ？」 でした。

明らかに純粋主義者は、プラットフォームの変更に後方互換性がない場合にのみメジャーバージョン番号が変わると言うでしょう。しかし、あなたは実際に後方互換性をドロップするつもりです今まで？多くの場合、メジャーバージョンの改訂は技術的な決定ではなくマーケティング上の決定です。Javaの不条理は、両方の陣営が同時に道を進んでおり、ほぼコミカルな効果をもたらしています。

最後に
に、先ほど述べたように、バージョン番号はテクノロジーに関するものと同じくらい多くの場合マーケティングに関するものです。それは問題ありません。それは、バージョン番号の種類であるためです。ソフトウェアの最新情報を一目で知ることができます。大きな変更は、機能の大きな変更を意味します。数の小さな変更は、機能の変更がほとんどないことを意味します。それは人々が期待するものです。真実かどうかによって、バージョン番号がユーザーが考えているのと同じ意味を持つかどうかが決まります。

-編集-
私はこれについて言及するのを忘れましたが、カレブはそれをうまく指摘しました：バージョン番号を使用して、重要なもの（例：安定/不安定）を明示しないでください。はい、あなたは奇数のマイナーバージョン番号が開発を示していることを知っていますが、それは私たちの一人になります。Debianの「不安定な」リリースモニカーは良い例です。または、まったく別の製品名を使用することもできます。製品名には「Frozbot 1.2」、開発バージョンには「Devbot 1.3」。

不安定なブランチは安定していると見なされます。たとえば、1.5.3では、1.4.0としてリリースします。

いやいや。不安定な1.5.3の場合、安定版は1.6.0から開始する必要があります（セマンティックバージョニングを使用したい場合は1.4.xが欠落しています）。

1つの値を使用して、2つの別々のことを示しようとしています。

最初に、「バージョン」があります。これは通常、さまざまなリリースを識別し、リリースが行われた順序を示すのに役立ちます。Tylerlが言ったように、バージョンを1.5.3から1.4.0に変更すると、バージョンは常に増加するはずです。ユーザーにとっては意味がありません（また、内部で多くの混乱を引き起こす可能性があります）。

次に、特定のバージョンが安定しているかどうかを示しようとしています。

それはです可能一部の店舗が価格体系を使用して商品が販売されているかどうかを示すのと同じように、単一の「バージョン番号」で両方を示すます。たとえば、近くの店で「3」で終わる価格は最終販売価格です。これは従業員にとってはうまく機能します。従業員はセール価格を見つける方法をすぐに学びますが、セールについて顧客に伝えるのに最適な方法ではありません。そのため、彼らはまた、販売アイテムの近くに看板を掲げました。安定したリリースの最下位桁を偶数にし、実験的なリリースでは奇数にするなど、同様のことができます。ただし、実験的なものをリリースする場合は、そのように明確にマークする必要があると思います。次のように、バージョン文字列の先頭または末尾に「X」を追加できます。。その後、実験的なバージョン番号を付けることもできます。そのため、同じベースバージョンに基づいて複数の実験的なバージョンをリリースできます：、。X.1.5.31.5.3.X1.5.3.X11.5.3.X2

また、「アルファ」および「ベータ」バージョン番号を使用して、安定または完全ではないバージョンを示す長い伝統があることも考慮する必要があります1.5.3a54。開発者コミュニティに何か他のことを説明する必要があるので、何か他のことをすることに決めた場合、このスキームから逸脱する正当な理由があることを確認してください。

major.minor.patch形式を使用することをお勧めします。安定版/不安定版には拡張子「タグ」を使用し、メジャー番号とマイナー番号の明確な意味を使用します。

major.minor.patch-stable|unstable

どこ

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

この方法で依存関係は簡単に管理され、各コンポーネントのクライアント/ユーザーが新しいバージョンにもっと注意を払う必要がある場合に通知されます。たとえば、コンポーネントA（1.1.0-stable）がB（5.4.534-stable）に依存しており、Bの新しいバージョンの期限が切れている（6.1.0-unstable）場合、Aはおそらく大幅に変更する必要があることをすぐに認識します。 。

Hibernating Rhinosがバージョンに対してRavenDbを構築している方法が大好きです。ビルド数が増え続けています。安定したものを取得すると、安定とマークされます。しかし、すべてがリリース候補です。