現在、友人のために小さなデスクトップアプリケーションを作成していますが、私は主に自分自身の学習体験としてそれを行っています。教育を受けて正しいことをするという精神で、このアプリのバージョン番号が欲しいです。
私の研究はこれらの関連する結果をもたらしました
ただし、アルファ、ベータ、リリース候補、およびcの番号付けに対処するものはありません。1.0未満のバージョン番号の規則は何ですか？私は彼らがしばらく続けることができることを知っています。たとえば、PuTTYは少なくとも10年間使用されており、まだバージョンベータ0.60のままです。
回答:
本当にプロジェクト次第です。一部のプロジェクトはバージョン1.0をリリースしていません。
MAMEの開発者は、エミュレータプログラムのバージョン1.0をリリースするつもりはありません。アーケードゲームは常に存在するため、真に「完成」することはないという議論があります。バージョン0.99の後には、バージョン0.100が続きました（マイナーバージョン100> 99）。同様に、Xfire 1.99の後に1.100が続きました。6年間の開発後、eMuleはまだバージョン0.50に達していません。ウィキペディアでのソフトウェアのバージョン管理
バージョンに番号を付ける一般的な方法の1つ（私が使用し始めたもの）は、セマンティックバージョニングです。
このスキームでは、バージョン番号とその変更方法は、基礎となるコードと、あるバージョンから次のバージョンに変更されたものについての意味を伝えます。
それがどのように機能するかについてのより多くのアイデアを提供し、および/またはあなたの質問のいくつかに答えるためのいくつかの引用：
1.0.0のリリース時期を知るにはどうすればよいですか？
ソフトウェアが本番環境で使用されている場合、おそらくすでに1.0.0になっているはずです。ユーザーが依存するようになった安定したAPIがある場合、1.0.0である必要があります。後方互換性について多くのことを心配しているなら、おそらくすでに1.0.0になっているはずです。
これは、迅速な開発と迅速な反復を妨げませんか？
メジャーバージョン0は、すべて迅速な開発に関するものです。毎日APIを変更する場合は、バージョン0.xxのままにするか、次のメジャーバージョンで作業する別の開発ブランチにする必要があります。
パブリックAPIに対するわずかな後方互換性のない変更でもメジャーバージョンバンプが必要な場合、バージョン42.0.0に非常に急速に移行することはありませんか？
これは責任ある開発と先見性の問題です。互換性のない変更は、多くの依存コードを持つソフトウェアに軽く導入しないでください。アップグレードに要する費用は非常に大きくなる可能性があります。互換性のない変更をリリースするためにメジャーバージョンをバンプしなければならないということは、変更の影響を熟考し、関連するコスト/利益比を評価することを意味します。
「アルファ」、「ベータ」などのリリースを指定する方法に関するルールもあります。詳細については、http：//semver.org/をご覧ください。
[編集]別の興味深いバージョン番号付けスキームは、MongoDBが使用するものです：
MongoDBは、開発リリースに奇数バージョンを使用します。
MongoDBバージョンには3つの数字があります：ABC
- Aはメジャーバージョンです。これはめったに変更されず、非常に大きな変更を意味します
- Bはリリース番号です。これには、後方互換性を破壊する可能性のある機能や事柄を含む多くの変更が含まれます。Bでさえ安定したブランチになり、奇数のBは開発になります。
- Cはリビジョン番号であり、バグとセキュリティの問題に使用されます。
例えば：
- 1.0.0：最初のGAリリース
- 1.0.x：1.0.xのバグ修正-アップグレードすることを強くお勧めします。リスクはほとんどありません
- 1.1.x：開発リリース。これには、完全には完成しておらず、進行中の新機能が含まれます。1.0とは異なる場合があります
- 1.2.x：2番目のGAリリース。これは1.1.xリリースの集大成です。
そのような「標準」があるとは思わない。
リリース候補には、リリースする可能性のあるバージョンの数に応じて、通常「[version] RC 1」などの規則があります。
製品の非常に初期のバージョン（機能が完全ではないバージョン）をリリースする場合は、バージョン "0"を使用することをお勧めします。そうすることで、機能セットに記入するにつれて、バージョンを徐々に増やすことができます。
リリース候補のような「アルファ」と「ベータ」を使用します-期間限定バージョンでは、フルバージョンのリリースに近いと思われることを示します。
ソフトウェアのバージョン管理に関するウィキペディアのページがあります。1.0以前のバージョンを共有するために、Appleや他の人が使用している規則がうまく機能します。したがって、最初の内部バージョンは1.0.0d1になります。
完全に内部のリビジョンの場合、タイムスタンプで十分です。
ほとんどの場合、各開発者は使用する標準を決定します。一般に、小数点の左側の数字は、平均的なユーザーにとって非常に目立つ可能性が高い大きな改訂を示します（つまり、機能やインターフェースの変更など）。小数点の右側にあるのは、変更/修正/追加であり、全体的な機能とデザインはほとんど変更しませんが、プログラム自体について何かを変更しますセキュリティの問題）。その後、さらに小数点を追加すると、これらの右側の数字はますます小さな変更（つまり、小さなバグ修正/セキュリティの問題など）を示します。
他の人が言ったように、正確な標準はないようです。私たちの組織では、次の表記法を使用しています。
リリース1.0 ---> 2.0（製品に追加された主要な新機能/改良機能）
リリース1.0 ---> 1.1（製品に追加された中レベルの新機能/改良機能）
リリース1.0 ---> 1.001（バグ修正）
「バージョン1.0」のマイルストーンは、経験豊富なコンピューターユーザーにとって非常に重要です。これは、プログラムが完了し、期待どおりに機能することを意味するためです。バージョン「0.something」の内容は、プログラマー自身がプログラムがまだ完了していないと考えていることを意味します。
機能の主要な成果のために「0.1」、「0.2」...バージョン番号を保持し、十分にきめ細かい日付とタイムスタンプであるビルド番号でサブセットすることができます。