バージョン番号を確認するにはどうすればよいですか？

私の会社は製品を製造しています。SVNによってバージョン管理される予定です。これはウェブアプリなので、基本的に、一部の機能を備えていないバージョンが存在しないため、常にベータ版としてラベル付けできます。しかし、それは企業向け製品になるので、そこに「不安定な監視」をしたくありません。では、どのようにバージョン管理を行いますか？1.0は安定していますか？ビルド日付はバージョン番号に含める必要がありますか？君たちがどう思うか教えて！

[ メジャー ]。[ マイナー ]。[ リリース ]。[ ビルド ]

major：本当にマーケティングの決定。バージョン1.0を呼び出す準備はできていますか？同社はこれを、顧客が追加料金を支払わなければならない可能性があるメジャーバージョンと見なしますか、それとも無料である可能性がある現在のメジャーバージョンのアップデートですか？R＆Dの決定ではなく、製品の決定です。

マイナー：メジャーがインクリメントされるたびに0から始まります。公開されるすべてのバージョンで+1。

release：開発マイルストーンに達して製品をリリースするたびに、内部的に（たとえば、QAまで）、これを増分します。これは、組織内のチーム間のコミュニケーションにとって特に重要です。言うまでもなく、同じ「リリース」を2回（内部的にも）リリースしないでください。minor ++またはmajor ++で0にリセットします。

build：SVNリビジョンの可能性があります。これが最も効果的です。

例
私の現在のクロム：83.0.4103.61

xyzg

gの増分は不安定です。（またはRC）zの増分は安定しており、バグ修正を意味します。
yの増分は安定しており、新しい機能を意味します。
xの増分は安定しており、100％下位互換性のないメジャーリリースです。

私はかつて、私の大規模なプロジェクト用に精巧な「バージョン管理スタイルガイド」を書きました。プロジェクトの具体化に失敗しましたが、スタイルガイドは引き続きオンラインで利用できます。それは私の個人的な意見ですが、おそらくあなたに役立つ（またはインスピレーションを与える）でしょう。

注意してください、それは長いテキストであり、コンポーネントのバージョン管理と製品のバージョン管理などに行きます。それはまた、OSSコミュニティで人気のあるいくつかのバージョン管理スキームについて強い意見を表明していますが、私はそれらを持っているので、それらを表明します。;-)

たとえば、Subversionのリビジョン番号を使用することに同意しません。TRUNKでの開発を継続しながら、リリースされたバージョンを維持したい場合があるので、メンテナンスブランチを設定します-リビジョン番号のバージョン管理は無駄になります。

編集：要約として、バージョンファイルのソースファイル、コンポーネント、および製品全体を区別します。コンポーネントと製品に別々のxy versoningのシステムを使用し、2つのコンポーネント間の優れた相互依存性により、どのコンポーネントバージョンがどの製品バージョンに属しているかの追跡が簡単になります。また、システムを壊すことなくアルファ/ベータ/リリース/パッチサイクルを処理する方法についても説明します。実際には、これは開発サイクル全体の手口なので、チェリーピックすることをお勧めします。;-)

編集2：十分な数の人が私の記事がこれを「良い答え」にするのに役立つと思ったので、私は再びその記事に取り組み始めました。PDFとLaTeXのバージョンが利用可能になりました。時間を見つけるとすぐに、より優れた言語と説明グラフィックを含む完全な書き直しが続きます。投票ありがとうございます！

ウィキペディアからインスピレーションを得てください：「ソフトウェアのバージョン管理」

もう1つの「新しい」「比較的人気のある」オプションは、セマンティックバージョニングです。

概要：

バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。

1. 互換性のないAPI変更を行った場合のメジャーバージョン
2. 下位互換性のある方法で機能を追加する場合のマイナーバージョン
3. 下位互換性のあるバグ修正を行う場合のパッチバージョン。

プレリリースおよびビルドメタデータの追加のラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。

あいうえお

インクリメント：
- D：バグ修正
- C：メンテナンス、例えば性能向上
- B：新機能
- ：アーキテクチャの変更

必須のものは最も左側にあるものです。たとえば、新機能や修正されたバグがある場合は、bをインクリメントするだけです。

複雑なエンタープライズプラットフォームレベルの依存関係管理とリリースのバージョン管理に関する私の経験に基づいて、私は半セマンティックバージョニングと呼ぶようなアプローチを推奨するようになりました。

基本的にはSemantic Versioning 2.0から構築されますが、それほど厳密ではありません。

半セマンティックバージョンセグメント：

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

主要リリースセグメントの形式：

MARKETTING.MAJOR.MINOR.PATCH

各セグメントでは英数字を使用できますが、論理的な増分変更には純粋な数値をお勧めします。

SemVerと同様に、私はメジャー、マイナー、およびパッチのコンポーネントに逆互換性の階層を表すことをお勧めしますが、マーケティングコンポーネントを追加することもお勧めします。これにより、製品の所有者、機能のエピック/グループ、およびビジネス上の懸念が、技術的な互換性の懸念とは無関係に主要コンポーネントにぶつかることができます。

他の回答とは異なり、プライマリセグメントにビルド番号を追加することはお勧めしません。代わりに、「+」の後にポストリリースセグメントを追加します（例：1.1.0.0 + build.42）。SemVerはこのビルドメタデータを呼び出しますが、ポストリリースセグメントの方がわかりやすいと思います。このセグメントは、サフィックスデータをプライマリリリースセグメントの互換性情報に関連しないものとして宣言するのに最適です。。継続的インテグレーションビルドには、以前のリリース番号に増分ビルド番号を付加して、各プライマリリリース後にリセットできます（例：1.1.0.0-> 1.1.0.0 + build.1-> 1.1.0.0 + build.2-> 1.1.0.1）。代わりに、ここにsvnリビジョン番号またはgit commit shaを入れて、コードリポジトリと簡単に結び付けることを好む人もいます。別のオプションは、ホットフィックスとパッチにリリース後のセグメントを使用することですが、そのために新しいプライマリリリースコンポーネントを追加することを検討する価値があります。バージョンは事実上左揃えで並べ替えられているため、パッチコンポーネントがインクリメントされると常に削除されます。

リリースセグメントとリリース後セグメントに加えて、多くの場合、プレリリースセグメントを使用して、アルファ、ベータ、リリース候補などのほぼ安定したプレリリースを示します。これに対するSemVerのアプローチはうまく機能しますが、英数字の分類子から数値コンポーネントを分離することをお勧めします（例：1.2.0.0 + alpha.2または1.2.0.0 + RC.2）。通常、リリースセグメントをバンプすると同時にリリース後セグメントを追加し、次にプライマリリリースセグメントをバンプするときにプレリリースセグメントを削除します（例：1.0.1.2-> 1.2.0.0-RC.1- > 1.2.0.0）。プレリリースセグメントは、リリースバージョンが近づいていることを示すために追加されます。通常、より詳細なテストと共有のための固定された機能のセットであり、より多くのコミットに基づいて刻々と変化しません。

ほとんどすべてのユースケースをカバーする方法でこれらすべてを意味的に定義することの利点は、標準的な方法でそれらを解析、ソート、比較、および増分できることです。これは、それぞれが独自に管理された依存関係を持つ、独立してバージョン付けされた多数の小さなコンポーネント（マイクロサービスなど）を持つ複雑なアプリケーションにCIシステムを使用する場合に特に重要です。

興味があれば、セミセマンティックパーサーをrubyで作成しました。このパターンを使用するだけでなく、それを使用した他のアプリを管理できるようにする必要がありました。

「バージョン番号」は、内部バージョン管理システムの問題です。リリース番号は別の問題です（KEPTは異なるはずです）。

単純なMAJOR.MINORリリースシステム（v1.27など）を使用します。MAJORは互換性レベル（バージョン2.xはバージョン1.xと互換性がないか、少なくともバージョン1.xと大きく異なります）、MINORはバグ修正リリースまたはマイナー拡張です。XY形式に従う限り、YEAR.MONTH（2009.12）やYEAR.RELEASE（2009.3）などの他のシステムも使用できます。しかし、本当に正当な理由がない限り、MAJOR.MINORを使用するのが最善でしょう。

ディストリビューションやアナウンスWebサイトなどがうまく機能せず、それだけでプロジェクトの人気に深刻な影響を与える可能性があるため、XY形式に適合しないものは絶対に使用しないでください。

（できれば分散された）バージョン管理システムでブランチとタグを使用して、特定の内部バージョン番号をそれぞれMAJORSとMINORSに関連するものとしてマークします。

そして、はい、1.0は安定しているはずです。アルファ、ベータ、またはRCとマークされていない限り、すべてのリリースは安定しているはずです。既知の壊れた不完全な部分にはAlphaを使用してください。既知の破損のベータ版。「試してみてください。見逃したものを見つけるでしょう」のRC。これらのいずれもないものは、（理想的には、もちろん）テストされ、既知であり、最新のマニュアルなどが必要です。

最近では、Subversionのリビジョン番号だけを使用するのが一般的です。

それがSVNにある場合、SVNリビジョン番号を使用しないのはなぜですか？

このWebページの右下を見ると、SVNリビジョン番号であるスタックオーバーフローのバージョン番号が表示されます。

バージョン管理はあなた次第です。一部のソフトウェアベンダーは1.0に悪い評判を与えているため、自信を持って最初のバージョンに1.0を付けました。

バージョン番号を使用するビルドに正確に関連付ける何らかの方法が必要ですが、エンドユーザーにとってはわかりやすくシンプルなものにしたいと思うでしょう。標準のバージョン番号を使用し、バージョン番号を含めてSVNリポジトリにタグを付けることを検討してください。

Subversionのリビジョン番号をそのまま使用するのは素晴らしくシンプルですが、バージョン番号から情報が削除されます。ユーザーはこれを悪いことと考えるかもしれません。

私はあなたのwebappが何らかの配備手順を持っていると思います、それでSubversionの各リビジョンが実際に公開されるわけではありません。「外部」から（ユーザーの観点から）リリースが行われる時期、およびコードがリリース間でいくつの改訂を受けるかを決定することは不可能であるため、数値はほぼランダムになります。彼らは増加するだろう、と私はそれを推測することは可能だと思ういくつかのあまりない、二つのリビジョンを比較するとの距離のようなものを。

従来のバージョン番号はリリースを「ドラマ化」する傾向があるため、ユーザーはある種の期待を抱くことができます。「私はバージョン1.0を持っていますが、バージョン1.1はこれを追加し、それは興味深いですね」と考えるのは、「昨日SOリビジョン2587を実行しました。今日は3233です。はるかに優れているはずです！」と考えるよりも簡単です。

もちろん、このドラマ化はさらに膨らむ可能性があり、企業は製品の実際の違いによって動機付けされているよりも興味深い音を出すことを意図したバージョン番号を選択しているため、リビジョン番号のカウンターを少し使用すると思います。

バージョンスキーム：[メジャー]。[マイナー]。[devrel] [マーク]
[メジャー]：開発に大幅な変更がある場合は増分します。
[マイナー]：開発にマイナーな変更がある場合は増分します。
[devrel]：バグ修正がある場合は増分します。major ++またはminor ++の場合はゼロにリセットします。
[マーク]：a、bまたはrc：aはアルファリリース、bはベータリリース、rcはリリース候補です。1.3.57aまたは1.3.57bまたは1.3.57rcなどのバージョンは、バージョン1.3.57より前であることに注意してください。0.0.0から開始します。

メジャーバージョンをいつ増やすかを決定するのに時間がかかりすぎました。いくつかのショップはめったにそれをしないので、あなたは1.25.3のようなリリースを持っているでしょう、そして他のものはあなたに15.0を与えてこれまでのリリースのためにそれをするでしょう

私はそれにうんざりしており、メジャーリリース番号は年であり、マイナーは年内の順次リリースにすぎないことを誰もが確信している。ユーザーはそれを気に入っているようで、次のバージョン番号を考え出すのは簡単です。

Year.Release.build

• 年=現在の年
• release =新しい機能を備えた公開リリースのシーケンス番号-毎年1にリセット
• ビルド=バグ修正と内部リリースのために増加

編集

**これは継続的に強化された内部アプリ用です**

これはおそらく、マーケティングおよび財務目的で年間のさまざまな時期にメジャーリリースを行うことが重要な商用アプリでは機能しません。

この質問が存在する理由は、構成管理を行う単一の合意された方法がないためです。

バージョン番号を作成する方法は、整数を1からインクリメントするだけです。説明または文書化する必要があるマルチパートバージョン番号は必要ありません。また、SVNリビジョン番号を使用したくないので、説明も必要です。

これを実現するには、SVNの上にいくつかのリリーススクリプトが必要です。

私はその地域での経験がほとんどありません。ただし、ここでは私がやることです：

1. リビジョンに番号を付けるためのスキームを選択し、それに固執します。一貫している。
2. 各バージョンの変更は、重要な変更を表す必要があります。変更がどれだけ小さいかは重要であり、バージョン番号に反映される変更のレベルはあなた次第です。

もちろん、svnリビジョン番号を使用することもできます---他の多くの人が提案しているように!!!

これがお役に立てば幸いです。

単純なmajor.minor.julian_date構文を使用します。

どこ;

• メジャー-最初のリリースは1であり、主要な新機能や変更を導入する際に、下位互換性がないため、この数を増やします。
• マイナー-メジャーマイルストーンリリース。プロダクションによってプッシュされるビルドごとに、この数は増加します。
• julian_date- ビルドがQAにプッシュされたユリウス日。

1/15にQAにプッシュされた最初のリリースの
例は-> 1.0.015 3/4にプロダクションにプッシュされた最初のリリースの例は-> 1.1.063です。

完璧ではありませんが、ビルドを毎日ほぼQAにプッシュするので便利です。

ここにいくつかの良い情報：

ファイル/アセンブリのバージョンをいつ変更するか

まず、ファイルのバージョンとアセンブリのバージョンが一致している必要はありません。ビルドごとにファイルバージョンを変更することをお勧めします。ただし、同じファイルの2つのバージョンの違いがわかるように、ビルドごとにアセンブリバージョンを変更しないでください。そのためのファイルバージョンを使用します。アセンブリバージョンをいつ変更するかを決定するには、検討するビルドのタイプ（出荷と非出荷）についてある程度の議論が必要です。

非出荷ビルド一般に、出荷ビルド間で非出荷アセンブリのバージョンを同じに保つことをお勧めします。これにより、バージョンの不一致による厳密な名前のアセンブリ読み込みの問題を回避できます。ビルドごとに新しいアセンブリバージョンをリダイレクトするために発行者ポリシーを使用することを好む人もいます。ただし、非出荷ビルドの場合はこれをお勧めします。ロードの問題をすべて回避できるわけではありません。たとえば、パートナーがアプリをコピーする場合、パートナーはパブリッシャーポリシーをインストールすることを知らない可能性があります。そうすれば、あなたのマシンでうまく機能しても、彼らのアプリは壊れてしまいます。

ただし、同じマシン上の異なるアプリケーションをアセンブリの異なるバージョンにバインドする必要がある場合は、それらのビルドに異なるアセンブリバージョンを提供して、LoadFromなどを使用せずにアプリごとに正しいバージョンを使用できるようにすることをお勧めします。

ビルドの配布ビルドを配布するためにそのバージョンを変更するのが適切かどうかは、エンドユーザーに対してバインディングをどのように機能させるかによって異なります。これらのビルドをサイドバイサイドにするか、インプレースにするか。2つのビルドの間に多くの変更点がありますか？彼らは何人かの顧客を壊すつもりですか？それらが壊れることを気にしますか（または、ユーザーにあなたの重要な更新を強制的に使用させたいですか）？はいの場合は、アセンブリバージョンの増分を検討する必要があります。しかし、繰り返しになりますが、これを何度も行うと、ユーザーのディスクに古いアセンブリが散らばる可能性があることを考慮してください。

アセンブリバージョンを変更する場合ハードコードされたバージョンを新しいバージョンに変更するには、ヘッダーファイルのバージョンに変数を設定し、ソースのハードコーディングを変数に置き換えることをお勧めします。次に、ビルド中にプリプロセッサを実行して、正しいバージョンを入れます。変更前のバージョンではなく、出荷後すぐにバージョンを変更することをお勧めします。これにより、変更によるバグを検出するための時間が長くなります。

または、「思考」バージョン番号のコンマsubversion番号を使用します。zB：

1.0.101 //リビジョン101、リリース

または1.0.101-090303 //リリース日で、これを使用します