ソフトウェアバージョン番号としての日付

ソフトウェア開発者は通常、日付をバージョン番号として使用しませんが、YYYYMMDD形式（またはそのバリエーション）は十分に堅実に見えます。そのスキームに何か問題はありますか？または、限定された「タイプ」のソフトウェアのみに適用されますか（社内制作など）。

これは、ユーザーとソフトウェアおよび開発者のニーズを考慮する必要があるため、いくつかの異なる角度から見なければならないものです。

一般的に、お客様は、新しいバージョン（Product 2012がProduct 2010よりも新しい）を実行していること、およびそれを知っている限り、ソフトウェアのバージョン番号がどうなるかについてあまり気にしません。展開できるパッチがある場合は最新です（つまり、Product 2012、Update 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つのスキームは、実際には連続展開が使用されている環境（スタック交換など）には適用されません。スタック交換で使用されているように見える日付とそれに続くリビジョン番号を好む傾向がありますサイト。これは、継続的なデプロイメント環境ではバージョンが頻繁に変更されるため、同じ日に複数のバージョンのコードが更新される可能性があるため、リビジョン番号と現在の日付が問題を解決するのに適しているためですさらにもっと。理論的には、すべてにリビジョン番号を使用できますが、現在の日付を使用すると、内部の主要なマイルストーンを追跡できます。

日付を使用する場合の問題は、指定された日付ではなく、カウント数に対して仕様が記述されることです。

「この機能の一部はリリース1になる予定です。他の機能の一部はリリース2になる予定です。」

リリース日が見落とされる可能性があるため、仕様で日付を参照することはできません。

事前に特定された異なるリリースを必要とするような正式なプロセスがない場合は、日付を使用しても問題ありません。別の番号をミックスに追加する必要はありません。

バージョン番号は、コンテキストが仕様にリンクされているため、日付を含むことはほとんどありません。
ビルド番号には日付が含まれている可能性があります。これは、ビルドのコンテキストがビルドが行われたときにリンクされているためです。

説明したように、このアプローチには利点がありますが、日付をバージョン番号として使用する場合、いくつかの欠点があります。

• 日付ベースのバージョンはフラットです。v2.1.3では、バージョン番号、サブバージョン番号、およびサブサブバージョン番号を確認できます。20110119では、いつ作成されたかを確認できます。あなたは可能性月別グループあなたの日付ベースのバージョンでは、それはまだあなたには何も言わないでしょう。数ヶ月の小さなバグ修正と、その後の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です。

リリースに関するドキュメントがある場合は、情報を2倍にして、そのバージョン20120109が2012年1月9日に到着したことを伝えます。うん しかし、最後の瞬間のバグ検出があり、リリースが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リビジョン番号を使用していると私は見ていますが、実際の問題はありません。

ここで既にいくつかの良い答えがありますが、日付を使用することが理にかなっているケースを指摘したいと思います：コードが頻繁に更新される可能性が高いが、以前と劇的に異なる単一のバージョンではない小さなビットのコードのスニペット1。

つまり、実際の「バージョン番号」はないが、基本的には準毎日のリポジトリダンプのような状況について話しているのです。

この種のものに出くわしたときは、特定のバージョンではなく比較的最新のスクリプト/ライブラリを使用していることを知る方が便利なので、この選択を歓迎します。

バージョン番号としての日付はマーケティングに適しています。「Windows NT 5.0」を使用している人は、それが時代遅れだと気付かないかもしれません。しかし、人々がまだ「Windows 2000」を使用している場合、彼らはそれが12年前のOSであることを即座に知り、アップグレードするよう奨励されます。

ただし、「メジャー」アップデートと「マイナー」アップデートを区別することは難しくなります。

日付をバージョン番号として使用する際の問題

ここでの答えは良いですが、日付の使用に関するこの懸念に対処する人は誰もいませんでした。ユーザーは、変更が行われた頻度を判断できません。

私が言おうとしているのは、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と同じ）。

要するに、日付のバージョン管理自体は価値があるとは思いません。

他の人によってすでに説明されている理由のため、私はこの考えが好きではありません。major.minor.bugfixスキームを使用するだけです-ほとんどの人がこの方法で行う理由があります。

しかし、あなたがすることは何でも：1つのバージョン命名スキームを選択し、それに固執します。Windowsのように、リリースごとにスキームを変更しないでください。また、Androidのようにしないでください。各リリースには、APIバージョン番号（8）、マーケティング用のバージョン番号（2.2）、愚かな名前（Froyo）があります。

バージョンとしての日付

製品が販売されていない場合は、日付を使用するだけで十分であり、おそらく便利です。それを販売して顧客にアップグレードする場合、特定の機能セットを備えたモデルを購入したいと考えています。このモデルに明確な名前があれば、アップグレードでそれらを販売する方がはるかに簡単です。実際にはそれが何であるかは重要ではありませんが、たとえば、2012年1月20日フォードカーを実際に購入する人はいません。ソフトウェアについても同じことが言えます。ハードモデル名とバージョンを指定すると、古いモデルとは異なる機能が使用されます。私にとっては、日付だけではそれができません、それは私がそれを作ったと言います、それは新しい機能を持っているかもしれません。

使用するスキーム

私たちのシステムは、上記のような明確なブランドを作成すると主張していません。 現在、4つの部分から成るスキームを使用しています。バージョン番号、状態、日付、チェックサム。

1200_GLD_120120_F0D1

これにより、継ぎ目がなくなる可能性がありますが、エンジニアが使用できるバージョン1200のビルドのいくつかのバージョンを用意し、日付ごとに区別することができます。状態は、それが内部テストバージョン、顧客パッチのビルドや金のリリースであれば人々に伝えます。チェックサムはそれがエンジニアまたは顧客は、彼らが実際に私達の分布から正しいものをダウンロードしていることを確認することを可能にする、新しいです。

そのため、次のシーケンスがあります。

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での作業を停止し、それ以降いくつかの重要なバグ修正のみをリリースした可能性があります。日付はバージョン番号とは無関係です。

うまくいくと思います。内部ソフトウェア（yyyy.mm.dd）とリリースしたオープンソースソフトウェアに使用します。

すべての場合に機能するとは限りません。

技術的には、バージョン番号に日付を使用することはできませんが、顧客の日付番号を表示できます。たとえば、macOS 16.7.23 ---つまり、2016年7月23日

技術は問題ではないと思います。問題はそれがどのように感じるかです。誕生日番号の男のように、ソフトウェアを生き生きとさせる日付番号を使用すると、毎年成長します。ソフトウェアと同じように成長し続けます。

建物番号は、機械、機械、生きていない、生きているようなものに見えます。