ソフトウェアバージョン番号としての日付
ソフトウェア開発者は通常、日付をバージョン番号として使用しませんが、YYYYMMDD形式（またはその差異）は使用するのに十分堅固に見えます。そのスキームに何か問題がありますか？それとも、ソフトウェアの限定された「タイプ」のみに適用されますか（社内制作など）？
これは、ユーザーやソフトウェアや開発者のニーズを考慮する必要があるため、いくつかの異なる角度から検討する必要があるものです。
一般に、顧客は、新しいものを実行している（つまり、製品2012が製品2010よりも新しい）ことを知っていて、それを知っている限り、ソフトウェアのバージョン番号をあまり気にしません。展開可能なパッチ（つまり、製品2012、アップデート10）がある場合は最新です。そのため、お客様のブランディングの観点からは、名前付きリリース（Windows XP、Windows Vistaなど）に続いて、ユーザーがインストールできる一連の厳密なパッチを優先する傾向があります。
とはいえ、ユーザーにとって簡単なことをチェックするソフトウェアを作成すると、内部でコードを作成するのがはるかに難しくなる傾向があります。したがって、単純なMajor.Minorバージョンスキームを好む傾向があるのは、次のように、単純な数値比較を行って、何かが最新かどうかを確認できるからです。
// Check to see if we can handle the file version
if (this.Version < fileVersion) {
throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...
ただし、これを少しコンテキストに当てはめると、通常、マイナー番号がどのくらい大きくなるか（つまり1.1024）が気にならないため、上記のシステムを正常に実行し続けることができます。一般に、リビジョン番号は内部開発にのみ関係し、実際に追跡番号を追加するだけで、それ以上の影響を与えることはありませんでした。
ただし、上記の2つのスキームは、継続的な展開が使用されている環境（Stack Exchangeなど）には実際には適用されません。つまり、Stack Exchangeで使用されているように、ある日付の後にリビジョン番号が続く傾向があります。サイト。この理由は、継続的デプロイメント環境ではバージョンが頻繁に変更されるため、同じ日に複数のバージョンのコードが実行される可能性があり、リビジョン番号を正当化し、現在の日付が物事を壊すのと同じくらい良いことです。さらにもっと。理論的には、すべてにリビジョン番号を使用できますが、現在の日付を使用することで、議論をより簡単にすることができる主要なマイルストーンを内部で追跡できます。
日付を使用する場合の問題は、仕様が期日ではなく日付ではなくカウント数に対して作成されることです。
「この機能の一部はリリース1に含まれる予定です。他の機能はリリース2に含まれる予定です。」
仕様で日付を参照することはできません。リリース日が見逃される可能性があるためです。
異なるリリースを事前に特定する必要があるような正式なプロセスがない場合は、日付を使用することで問題ありません。ミックスに別の番号を追加する必要はありません。
バージョン番号のコンテキストは仕様にリンクされているため、日付が含まれる可能性は低いです。
ビルド番号日付が含まれている可能性があります。これは、そのコンテキストがビルドがいつ実行されたかにリンクされているためです。
このアプローチには、説明したように利点がありますが、バージョン番号として日付を使用する場合、特定の欠点があります。
日付ベースのバージョンはフラットです。 v2.1.3では、バージョン番号、サブバージョン番号、サブサブバージョン番号を確認できます。 20110119では、いつ作成されたかを確認できます。あなたはcould日付ベースのバージョンを月ごとにグループ化しますが、それでも何もわかりません。数ヶ月の小さなバグ修正とその後の2週間の大量のコーディングにより、メジャーリリースになる可能性があります。日付ではわかりませんが、通常のバージョン番号ではわかります。
本当に本当に毎日バージョンを変更する必要があり、リリース番号を変更する必要がある場合は、適切なリリースプロセスがないことを示している可能性があります。その場合、プロセスに問題があり、別のバージョン番号スキーマを使用しても解決できません。
バージョンは、ソフトウェアの特定のバージョンが前のバージョンとどの程度異なるかについての情報を伝えるためによく使用されます。したがって、たとえば、Acmeを1.0から2.0にアップグレードした場合、それは大きなアップグレードであり、理論的には大きな変更を伴います。
一方、1.0から1.1へのアップグレードはマイナーアップグレードであり、理論的にはマイナーな増分変更とバグ修正が含まれています。
これを日付形式で表現することは困難ですが、混合することもできます。たとえば、v1.0.YYYY.MMDD
他の答えから良いアイデアを繰り返すことなく、まだ対処されていない問題が頭にあります。
下位互換性のための古いバージョンと互換性のない最新化のための新しいバージョンの間で分岐が発生した場合、バージョン番号でそれらを区別することはできません。
たとえば、Linuxカーネルは2000年頃に古い2.4.xブランチに分岐しました。これはおそらく現在もサポートされており、2.4.199としてカウントされますが、新しいバージョンは長年にわたって2.6であり、2.6.32です。古いシステムの場合は3.2、最新のカーネルの場合は3.2。
リリースに関するドキュメントがある場合は、情報を2倍にして、人々に伝えます。バージョン20120109は2012年の01/09に到着したことです。んしかし、最後の瞬間のバグ検出があり、リリースが1週間遅れるが、名前が記載されているドキュメントがすでに準備されていて、おそらく印刷されている場合、プレス情報は公開されます。これで、バージョン20120109が2012/01/13に到着した場合、問題のある矛盾が生じます。
SQLでは、IDがセマンティック情報を伝達する必要があるかどうかという問題が頻繁に議論されてきましたが、その結果は常に次のとおりです。不要な依存関係を作成しています。メリットはありません。
その04/10スキームを備えたUbuntuには、バージョン6.04が遅延して6.06になった2006年に問題がありました。 3000年にはすぐに次の問題があります！ :)
実際に日付をバージョンとして使用する多くのソフトウェアパッケージがあります。 Ubuntuが思い浮かびます。バージョンはYY.MMです。 Microsoft Office製品のビルド番号 もビルド日付のエンコードです。 Jeff Atwoodがバージョン番号付けに関するCoding Horrorブログ投稿を書いた 、この推奨事項を含む：
特に製品のパブリックネームでは、可能な限り、バージョン番号の代わりに単純な日付を使用してください。そしてもしあなたが絶対的に積極的にバージョン番号を内部的に使用しなければならないなら、とにかくそれらを日付にしてください：ビルドの日付をバージョン番号のどこかにエンコードするようにしてください。
私の意見では、あなたが一貫していて、ビルドバージョン番号（それが何であれ）から移動でき、バージョン管理システムからそのビルドに入ったすべてのアーティファクトを呼び出すことができる限り、問題ではありません。ユーザーは通常、バージョン情報をまったく気にしませんが、システムが提供する機能を気にしません。バージョン情報は、開発者にとって真に価値のあるものです。
セマンティックバージョニングを使用します。これにより、コード自体を検査することなく、バージョン間で行われる変更の種類を把握できます。 http://semver.org/
バージョン番号を使用することは、変更がどれほど大きいかを示す方法です
たとえば2.4.3は、バージョン2がシステム全体の主要な変更であることを意味します。 .4はマイナーアップデートです。最後の.3は、そのバージョンに対する小さなバグ修正です。そうすれば、各バージョン間でどれだけ変化したかが簡単にわかります。
とは言っても、サポートリリースノートやそのリリースの対象範囲のドキュメントを追跡する方法がある限り、多くの人がバージョン番号として日付またはSCMリビジョン番号を使用していることはまだありますが、実際には問題はありません。
日付をバージョン番号として使用する際の問題
ここでの答えは良いですが、日付を使用することでこの問題に対処している人は誰もいませんでした。ユーザーは変更が行われた頻度を判断できません。
私が言おうとしているのは、Windows 3.1とWindows 7が離れていることと、互換性がない可能性があることです。 Windows 95とWindows 2000は、製品が導入された年にすぎません。
たとえば、Pythonでは、バージョン2.7.2が2.4.6から進化したことを知っています。さらに調べると、バージョン2.4.6が2008年12月19日にリリースされたことがわかります。そして、そのバージョン2.7.2が2011年6月11日にリリースされました。これから、製品の安定性（リリースの頻度）について意見を述べることができます。
代わりに、Pythonがリリース日を使用していた場合、これらの製品がどのように接続されるかを知ることができません。Python 3.1.4も2011年6月11日にリリース（Python 2.7.2と同じ）。
要するに、日付のバージョン管理だけでは価値があるとは思いません。
いくつかの良い答えはすでにここにありますが、日付を使用することが完全に理にかなっているケースを指摘したいと思います。コードが頻繁に更新される可能性が高いが、単一のバージョンが前のものと劇的に異なることのない小さなビットである小さなライブラリまたはコードのスニペット1。
言い換えれば、実際の「バージョン番号」はないが、基本的には1日あたりの準リポジトリダンプのような状況について話しています。
この種のものに遭遇したとき、特定のバージョンではなく比較的最新のスクリプト/ライブラリを使用していることを知っている方が便利なので、通常はこの選択を歓迎します。
バージョン番号としての日付は、マーケティングに適しています。 「Windows NT 5.0」を使っている人は、時代遅れだと気づかないかもしれません。しかし、人々がまだ「Windows 2000」を使用している場合、彼らは即座にそれが12年前のOSであることを知り、アップグレードするように促されます。
ただし、「メジャー」更新と「マイナー」更新を区別するのが難しくなります。
他の人がすでに説明している理由のため、私はこのアイデアが好きではありません。 major.minor.bugfixスキームを使用してください-ほとんどの人がこのようにする理由はあります。
しかし、あなたがすることは何でも：1つのバージョン命名スキームを選び、それに固執するです。リリースごとにスキームを変更するWindowsのようにしないでください。また、Androidのようにしないでください。各リリースには、APIバージョン番号（8）、マーケティング用のバージョン番号（2.2）、愚かな名前（Froyo）があります。
バージョンとしての日付
製品が販売されていない場合は、日付を使用するだけで十分です。あなたがそれを販売して顧客にアップグレードする場合、彼らは特定の機能セットを備えたモデルを購入したいと考えています。このモデルが明確な名前を持っている場合、アップグレードでそれらを販売する方がはるかに簡単です。たとえば、それが何であるかは重要ではありませんが、たとえば2012年1月20日のフォードカーを実際に購入する人はいないでしょう。ソフトウェアについても同様です。ハードモデル名とバージョンを指定することは、古いモデルとは異なる機能を持つことを意味します。私にとっては、日付だけではそれはできません。それは私がそれを作ったと言います、それは新しい機能を持っている可能性はありません。
使用するスキーム
私は、私たちのシステムが上記のように明確なブランドを作成することを主張しませんでした。現在、4つの部分からなるスキームを使用しています。バージョン番号、状態、日付、チェックサム。
1200_GLD_120120_F0D1
これは上から継ぎ目になるかもしれませんが、エンジニアが使用できるバージョン1200のビルドのいくつかのバージョンを持つことができ、日付によってそれらを区別できます。 stateは、内部テストバージョン、カスタマーパッチビルド、ゴールドリリースのどれであるかをユーザーに伝えます。 checksumは新しいものであり、エンジニアまたは顧客は、ディストリビューションから正しいものを実際にダウンロードしたかどうかを確認できます。
だから私たちは一連の
1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD
通常、お客様にはメジャーバージョン番号「12」のみを参照しますが、フィックスが必要でない限り、お客様は最新のゴールドバージョン12、つまり1200_GLD_120120_F0D1を取得します。
たとえば、製品のバージョン2を使用している顧客もいれば、バージョン3にアップグレードした顧客もいます。
たとえば、バージョン2の最後のバージョンが2.3.2で、バージョン3が3.0.3であるとします。ここで、絶対に修正する必要がある脆弱性を見つけたので、2.3.3と3.0.4を同じ日にリリースします。リリース日がまったく無関係であることがわかりますか？ 2013年にバージョン2の作業を中止し、それ以降、いくつかの重要なバグ修正のみをリリースした可能性があります。日付はバージョン番号とは関係ありません。