私の会社は製品を作っています。SVN によってバージョン管理されます。これは webapp であるため、基本的に、一部の機能が含まれていないバージョンがリリースされることはなく、常にベータ版としてラベル付けされる可能性があります。しかし、企業向けの製品になるので、そこに「不安定な監視」を付けたくありません。では、どのようにバージョン管理を行いますか? 1.0 は安定していますか? ビルドの日付をバージョン番号に含める必要がありますか? 皆さんの考えを教えてください！
59237 次
18 に答える
265
[メジャー].[マイナー].[リリース].[ビルド]
major : 本当にマーケティング上の決定です。バージョン 1.0 を呼び出す準備はできていますか? 同社は、これを顧客がより多くの料金を支払う必要があるメジャー バージョンと見なしていますか、それとも現在のメジャー バージョンのアップデートであり、無料である可能性があると考えていますか? 研究開発の決定ではなく、製品の決定です。
minor : majorがインクリメントされるたびに 0 から始まります。公開されるすべてのバージョンに +1。
release : 開発のマイルストーンに達して製品をリリースするたびに、内部 (QA など) であっても、これをインクリメントします。これは、組織内のチーム間のコミュニケーションにとって特に重要です。言うまでもなく、同じ「リリース」を 2 回 (内部であっても) 決してリリースしないでください。マイナー++またはメジャー++で0にリセットされます。
build : SVN リビジョンにすることができます。これが最適です。
例
現在のクロム: 83.0.4103.61
于 2009-03-05T15:31:26.280 に答える
11
あいうえお
増分 : 時期
- d : バグ修正
- c : パフォーマンスの改善などのメンテナンス
- b : 新機能
- a : アーキテクチャの変更
必須は一番左のものです。たとえば、新しい機能やバグが修正された場合は、bをインクリメントするだけです。
于 2014-12-18T17:16:31.130 に答える
9
複雑なエンタープライズ プラットフォーム レベルの依存関係管理とリリース バージョニングに関する私の経験に基づいて、セミセマンティック バージョニングと呼ばれるアプローチを推奨するようになりました。
基本的にはセマンティック バージョニング 2.0に基づいて構築されていますが、それほど厳密ではありません。
セミセマンティック バージョン セグメント:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
プライマリ リリース セグメントの形式:
マーケティング.メジャー.マイナー.パッチ
各セグメントには英数字を使用できますが、論理的なインクリメンタル変更には純粋な数値を使用することをお勧めします。
SemVer と同様に、Major、Minor、および Patch コンポーネントを使用して逆方向互換性層を表すことをお勧めしますが、Marketing コンポーネントを先頭に追加することもお勧めします。これにより、製品所有者、機能のエピック/グループ、およびビジネス上の懸念が、技術的な互換性の問題とは関係なく、プライマリ コンポーネントをバンプすることができます。
他の回答とは異なり、ビルド番号をプライマリ セグメントに追加することはお勧めしません。代わりに、 「+」の後にリリース後セグメントを追加します (例: 1.1.0.0+build.42)。SemVer はこれをビルド メタデータと呼んでいますが、Post-Release Segment の方がわかりやすいと思います。このセグメントは、主要なリリース セグメントの互換性情報に関連しないサフィックス データを宣言するのに最適です。. その後、継続的インテグレーション ビルドに以前のリリース番号を付与し、プライマリ リリースごとにリセットされる増分ビルド番号を追加できます (例: 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 で書きました。このパターンを使用するだけでなく、それを使用する他のアプリを管理できるようにする必要がありました。
于 2014-07-18T06:00:32.557 に答える
4
「バージョン番号」は、内部のバージョン管理システムの問題です。リリース番号は別の問題です（そしてKEPTは異なるはずです）。
単純なMAJOR.MINORリリースシステム（v1.27など）に固執します。ここで、MAJORは互換性レベル（バージョン2.xはバージョン1.xと互換性がないか、少なくとも大幅に異なります）であり、MINORはバグ修正リリースまたはマイナーな機能拡張です。 。XY形式に従う限り、YEAR.MONTH（2009.12）やYEAR.RELEASE（2009.3）などの他のシステムを使用することもできます。しかし、実際には、そうしない正当な理由がない限り、おそらくMAJOR.MINORに固執するのが最善です。
XY形式に適合しないものは絶対に使用しないでください。ディストリビューションやアナウンスのウェブサイトなどが連携しにくくなり、それだけでプロジェクトの人気に深刻な影響を与える可能性があります。
（できれば分散された）バージョン管理システムでブランチとタグを使用して、特定の内部バージョン番号をそれぞれMAJORSとMINORSに関連するものとしてマークします。
はい、1.0は安定しているはずです。アルファ、ベータ、またはRCのマークが付いていない限り、すべてのリリースは安定している必要があります。既知の壊れた不完全なものにはアルファを使用します。既知の壊れたもののベータ。「試してみてください。私たちが見逃したものを見つけることができるでしょう」のRC。これらのいずれかがないものはすべて（理想的にはもちろん）テストされ、良好であることがわかっており、最新のマニュアルが必要です。
于 2009-03-05T15:44:04.780 に答える
3
バージョン スキーム: [major].[minor].[devrel][mark]
[major]: 開発で大幅な変更があった場合にインクリメントします。
[マイナー]: 開発にマイナーな変更がある場合にインクリメントします。
[devrel]: バグ修正がある場合にインクリメントします。メジャー ++ またはマイナー ++ の場合はゼロにリセットします。
[マーク]: a、b または rc: a はアルファ リリース、b はベータ リリース、rc はリリース候補です。1.3.57a または 1.3.57b または 1.3.57rc のようなバージョンは、バージョン 1.3.57 より前であることに注意してください。0.0.0 から開始します。
于 2013-07-04T21:55:00.290 に答える
2
Subversion のリビジョン番号を使用するのは簡単ですが、バージョン番号から情報が削除されます。ユーザーはこれを悪いことだと考えるかもしれません。
Subversion の各リビジョンが実際に公開されるとは限らないように、webapp には何らかの展開手順があると思います。「外部」(ユーザーの観点) からは、いつリリースが行われるか、およびその間にコードが何回改訂されるかを判断することは不可能であるため、数字はほぼランダムになります。それらは増加し、2 つのリビジョンを比較することからある程度の距離を推測することは可能だと思いますが、それほどではありません。
従来のバージョン番号は、リリースを「ドラマチック」にする傾向があるため、ユーザーは何らかの期待を抱くことができます。「昨日は SO リビジョン 2587 を実行したが、今日は 3233 で、ずっと良くなっているに違いない!」と考えるよりも、「バージョン 1.0 を持っていて、バージョン 1.1 が出てきて、あれやこれやを追加して、面白そう」と考える方が簡単です。
もちろん、この脚色は膨らませることもできます。企業は、製品の実際の違いによって動機付けられるよりも、興味深いように聞こえることを意図したバージョン番号を選択しています。リビジョン番号を使用することで、これに少し対抗できると思います.
于 2009-03-05T15:28:08.597 に答える
2
それがSVNにある場合、SVNリビジョン番号を使用しないのはなぜですか?
この Web ページの右下を見ると、SVN リビジョン番号であるスタック オーバーフローのバージョン番号が表示されます。
于 2009-03-05T15:23:11.557 に答える
2
最近では、Subversion のリビジョン番号だけを使用することが非常に一般的です。
于 2009-03-05T15:23:22.100 に答える
1
この質問が存在する理由は、構成管理を行うための合意された方法が1つもないためです。
私がバージョン番号を作成するのが好きな方法は、1から整数をインクリメントすることです。説明または文書化する必要があるマルチパートバージョン番号は必要ありません。また、SVNのリビジョン番号も使用したくないので、説明が必要になります。
これを実現するには、SVNに加えていくつかのリリーススクリプトが必要になります
于 2009-03-06T17:44:58.477 に答える
0
シンプルな major.minor.julian_date 構文を使用します。
どこ;
- メジャー - 最初のリリースは 1 で、後方互換性がないほど重要な新機能や変更が導入された場合は、この数を増やします。
- マイナー - メジャー マイルストーン リリース。プロダクションによってプッシュされたビルドごとに、この数が増加します。
- julian_date -ビルドが QA にプッシュされたユリウス日。
1/15 に QA にプッシュされた最初のリリースの
例 -> 1.0.015 3/4 に本番にプッシュされた最初のリリースの例 -> 1.1.063
完璧ではありませんが、ほぼ毎日ビルドを QA にプッシュするので便利です。
于 2009-03-10T03:28:18.067 に答える
0
私はその地域での経験がほとんどありません。ただし、ここで私がすることは次のとおりです。
- リビジョンに番号を付けるためのスキームを選択し、それに固執します。一貫性を保ちます。
- 各バージョンの変更は、重要な変更を表す必要があります。重要な変更の程度と、バージョン番号に反映される変更のレベルは、ユーザー次第です。
もちろん、svn リビジョン番号をそのまま使用できます --- 他の多くの人が示唆しているように!!!
これが役立つことを願っています。
于 2009-03-05T15:30:29.493 に答える