versioning - バージョン番号付けに関するアドバイスはありますか?

Question

当社の製品には長い歴史があります (約 12 年)。

その起源は VB3 (バージョン 1) とそれ以降の VB6 (バージョン 2) にあります。(バージョン番号は「犬の朝食」であり、バージョン管理は悪夢でした。

私はここ数年ここに関わっています。バージョン 3 は .Net プラットフォームで開発中ですが、バージョン 2 は定期的なリリース (年間約 3 ～ 4) で引き続きサポートされています。

開始時にナイトリー自動ビルドを導入し、製品のバージョン番号は 2.2.2 でした。誰もが 2.2.3 をリリースする予定でしたが、自動化されたビルドプロセスと VB6 の「興味深い」3 つのパーツ番号システムにより、3 番目の部分であるビルド/リビジョン番号を使用する必要がありました。

そのため、バージョン 2.3 (ビルド番号は「なんでも」) をリリースし、2.4 (ビルド番号は毎晩インクリメント)、2.5、2.6 などの作業に取り掛かりました。

ビルド番号は公開されていませんが、バージョンの複数のビルドをリリースすることはめったにありませんが、サポート目的で利用できます。ただし、時々パッチを適用する必要があります.

一貫性が保証されます。これで 2.9 になりました。2.10 (2.10 から 2.10 まで) に移行しようとしています。残念ながら、非技術者はこれを有理数 (2 - ポイント 1) のように読んでいます。彼らは、私たちがバージョン 3.0 に移行しない理由を理解できません。(ビルド番号は、サポート目的で「ヘルプ/バージョン情報」画面にのみ表示されます)。

製品 (メジャー番号) のアップグレードは、特にこれが市場に設定する期待のために保証されているとは思いません.

ここで進む正しい方法はありますか？(2.10 か 3.0 か、それよりも優れたものか、それとも問題なのでしょうか?)

(注: バージョン番号が 2.9 ではなく 2.09 として表示されるように、(当社の Web サイト、製品のスプラッシュ画面、その他のさまざまな公共の場所などで) ある程度の努力をしました。そのため、2.10 に移行したときに、より理にかなっていますが、2.09 は実際には 2.8 よりも低い有理数であるため、これは潜在的に混乱を招く可能性があります...)

関連項目:

バージョン番号の決定

バージョン番号の付け方

使用するバージョン番号をどのように知ることができますか?

score 9 · Accepted Answer

非技術者が何かを学ぶチャンスと考えてください ;-) バージョン番号は、本の章や節の番号のようなものであるべきです。バージョン番号は、プログラムの寿命を一貫性のある内部的に一貫したブロックに分割します。

score 6 · Accepted Answer

独自のソフトウェアをどのようにバージョンアップするかは、あなた次第です。メンテナンス、リリース管理、カスタマーサポートの観点から何が最善かを除けば、「正しい」も「間違っている」もありません。重要なことは、バージョン管理を管理することです。つまり、あなたがバージョン管理を理解し、製品で作業するすべての人がそれを理解し、後で問題が発生しないようにすることです。3.0 とは対照的に、2.9 から 2.10 に変更しても意味はありませんが、意味はありません。

score 6 · Accepted Answer

他の答えは半分だけ正しいです。バージョン番号にはあなたが与える意味がありますが、他の人が与える意味もあります。ユーザーを修正するためにそこにいるつもりはないので、あなた自身の意味は本当に重要ではありません。2.9 から 3.0 への移行が大きな飛躍であると考えている場合は、そのように受け止めます。x.0 バージョンを使用することを恐れている場合は、使用しません。奇数番号のリリースがアルファ版であることに慣れている場合は、それらを使用しません。

言いたくないのですが、バージョン番号はマーケティングツールです。それらはリリースについてユーザーに何かを伝えるので、バージョン番号を選択するときはそれを考慮に入れる必要があります。

問題は、バージョン番号が人によって意味が異なることです。予測できるものもあります。上で述べたように、人々は x.0 リリースを疑うでしょう。彼らは、2.x から 3.x への大きな変更を期待しています。せっかく遊んでみたい方はどうぞ。

バージョン番号には 2 つの重要な属性があります。まず、それらは常に上昇する必要があります。第二に、簡単にソートできる必要があります。前者は明らかですが、後者はしばしば違反されます。バージョン 2.9 -> 2.10 を検討してください。数値的に言えば、2.9 は 2.10 より大きいです。正しく並べ替えるには、メジャー/マイナーバージョン番号を考慮する必要があります。このことから、2.10 または 3.0 のどちらが 2.9 に続くかについての混乱が生じます。並べ替えのルールを知っていても、まだ間違っているようです。このため、私は常に自分のバージョンをパディングします。2.09 の後に 2.10 が続きます。数値としてもドットペアとしても正しくソートされます。

それでもなお、数秘術師が宝くじの当選番号を選別するように、ユーザーはバージョン番号から意味を推測しようとします。そのゲームをプレイしようとすることも、やめることもできます。なぜドットペアを使用するのでしょうか。整数を使用します。それは明白です。それは簡単にソートされます。ユーザーがつかむのに誤った意味を与えることはありません。

私はもう1つうまくいくことができます。バージョン番号には明確な意味があり、便利なものです。CPANの世界では、バージョン 1.03 を使用していて最新版が 1.07 で、わずか .04 の違いしかないためにモジュールをアップグレードしないという問題があります。なぜわざわざアップグレードするのですか？それが示していないのは、1.03 から 1.07 までの間に 4 年あったということです。Microsoft はそれを理解したので、Office 12 の代わりに Office 2009 を購入しました (頻繁にリリースしないと、お尻を噛む可能性もあります。2001 年に Windows 98 が必要になる人がいるでしょうか?) バージョン番号に記載されています。「Widgets 2007」は、アップグレードを探す必要があるかもしれないことを教えてくれます。

以前は ISO 日付をバージョンとして使用していました。今日リリースした場合、バージョンは 20090309 になります。1 日に 2 つリリースする必要がある場合は、末尾に時間と分を追加してください: 20090309.2051。簡単に並べ替えます。いつも上がります。リリースについてユーザーに明確な意味を伝えます。ここに例があります。

私は現在、セマンティックバージョニングを使用しています。ドットトリプルを使用して、3 つの重要な情報を伝えます。API が壊れていませんか? 機能は追加されましたか？これは単なるバグ修正ですか？ユーザーは、プロジェクトがセマンティックバージョンを使用していることに注意する必要があります。これは、ISO 日付バージョンよりも不利です。利点は、それが伝達する情報の種類と、明確に定義されていることです。

score 5 · Accepted Answer

バージョン番号には常に少なくとも 3 つのコンポーネントを使用し、4 つ目以降のコンポーネント以外は非表示にしないことをお勧めします。どこでもその規則に固執してください。非技術者には、それが有理数になることはあり得ないことが明らかであり、他の何か (つまり、3 つの整数の合成) でなければならないからです。

2.8.0
2.9.0
2.10.0
2.11.0
...

また、ダイアログについて、バージョン番号の近くにビルド日 (yyyy-mm-dd) を貼り付けます。顧客がバージョン番号と混同している場合は、日付を比較するだけでよいため、通常の人にとってははるかに直感的です。

score 4 · Accepted Answer

2.9.1または2.10.1を実行することもできますが、数え続けるプロジェクトはたくさんあります。2.10、2.111213など。

score 3 · Accepted Answer

2.10に向けて正しいアプローチを追求したと思います。バージョン番号の主な目的は、新しい機能をグループ化し、定義可能なリリースバージョンに開発することです。番号付けがこれを妨げている場合は、別の番号付けスキームが必要です。

score 3 · Accepted Answer

2.10 で混乱が生じる場合は、スキップして 2.11 に進んでください。ただし、2.20 での同じ問題に備えましょう :)

score 2 · Accepted Answer

DLL などの内部バージョンからマーケティングバージョンを分離することをお勧めします。それらには異なるセマンティクスがあります。

score 1 · Accepted Answer

ウィキペディアには、ソフトウェアのバージョン管理に関する非常に優れた記事があります

長期にわたるプロジェクトに取り組んでいる場合、シーケンスベースの識別子 (1.0、2.0 など) はスケーリングしません。

私は個人的に、そのバージョンでリリースの年と月を使用しているUbuntuのバージョン管理スキームが好きです（そして好みます）。たとえば、Ubuntu 8.04 は 2008 年 4 月にリリースされました。

score 1 · Accepted Answer

ありがとう - ここには素晴らしい答えがたくさんあります。

「答えを受け入れる不安」がありますが、それぞれの答えから少しずつ取るのはおそらく正しいと思います。

まず、ここに善悪はありません。第二に、ナンバリングは何の邪魔にもなりません。

バージョン番号は、本の章やセクション番号のように考えることができます。これは、少なくとも私が考えているように、他の人に説明するのに本当に役立ちます.

技術/開発バージョンの番号付けからマーケティングのバージョン管理を分離/分離すると、すべてが解決します...ただし、これは長期的な答えです。

私は2.9に続くために2.10に固執しています-そして私は戦います...そして間違いなくUbuntuを調査します

score 1 · Accepted Answer

内部バージョン番号とは独立した方法でソフトウェアのバージョンをブランド化するように指示する必要があります。たとえば、iPhoto '09 は iPhoto バージョン 8.x です。マイクロソフトも同じことをしました。

明らかに、主要なベンダーは、開発者がバージョン番号を自由に使用できるようにしながら、機能リリースに関係するブランドバージョンに移行しています。これには誰もが満足し、マーケティング担当者は、ソフトウェアリリースのブランディング方法に関するまったく新しい戦略を考え出すことができるため、特に満足するでしょう。

score 0 · Accepted Answer

完全な書き直しを表すためにメジャーバージョン番号を使用することはありません。書き直すことはめったにないので、多くの従業員にとって、バージョン 1 は「ここで働く前」のものであると説明するだけで済みます。あなたの製品が「スタックオーバーフロー」と呼ばれていた場合、私は書き直したものを「スタックオーバーフロー」と呼び、古いものを「古いスタックオーバーフロー」と呼びます。これは、古いバージョンを移行する必要があることをユーザーに常に思い出させるものです。

versioning - バージョン番号付けに関するアドバイスはありますか?

12 に答える 12

Related

Reference