しかし、これはソフトウェアが古いとタッチの外にあるという印象を与えることができます（バージョンにありますどのように多くの商用アプリケーション20+ ??）私たちのアプリケーションはかなり成熟しているので、我々はバージョン16までです他の開発チームはどのようにバージョン番号にアプローチしますか？
明らかに、バージョン番号はかなり恣意的です - 他の人は何を使用していますか？私はmonth.dateのUbuntuのアプローチが大好きですが、人々が使っている他の戦略を見たいと思います。
我々は20が、あなたのケースでは、かなり高い「リリース」数か何かで1.20.5のようなもの、と行く傾向があります。我々異なる実装で完全に再書き込み製品、それがそうで2.0.0になり、
。
また、ベータ版は0.2.3とすることもできます。
私たちはそれを現在どのようにしているのですか？できます。 –
私はそれだけでバグ修正リリースのためにその旨を1.1または1.1.2か何かのようなサブバージョンの形式を使用するように、かなり標準だと思う、マイナーの追加、など...そして上の主なバージョン番号をインクリメントすることを計画メジャーリリース。
私の会社は19年のための製品を開発し、我々は唯一のバージョンである - 私たちはそうで1.2、1.5としていたが、3を。私はこれがベストプラクティスだと思う。
私たちは、マイクロソフト社のシステム（あるいは少なくともその文書化されたシステム - 実際のバイナリはかなり少ない一貫しているように見える）を使用：
バージョンパーツが変更されると、その下位のパーツはすべて独立して変更されるのではなく、ゼロにリセットされます。
クリスチャンが言ったように、我々はリリースの月 - 日と一緒にメジャー/マイナー番号を使用していました。
内部的には、CVSの日付を使用します。 私たちの場合、製品はかなり小さく、QAの人々と話すときはmd5sumを参照します。
バージョン番号を使用すると、技術者以外の人にアップグレードを販売することができます。これは、古いバージョンを使用していないソフトウェアベンダーや管理者のアップグレード承認を取得しようとするユーザーの観点からです。
「バージョン20」を使用していると言えば、すぐに誰にも何の意味もありません。
"Product X 2005"を使用していると言えば、誰もがそれが4歳の製品であることを理解しています。
（技術者はおそらくいずれにも気にしません）
プログラミングに関連しないのはなぜですか？それは確かです。 – erikkallen