バージョン番号はいつ増やすべきですか?


23

私は学校でプログラミングを学ばなかったし、(プロの)開発者として働いていないので、基本的なことの多くははっきりしていません。この質問では、そのうちの1つを明確にしようとします。


今度は、私は問題を抱えていると仮定しましょう#1#2そして#3バージョンの強化/修正されるように設定されている私の問題トラッカーで1.0.0、最後の(安定)バージョンであること0.9.0

いつバージョンを増やすべき1.0.0ですか?a)上記の問題の1つのみがクローズされた場合、またはb)バージョンに関連するすべての問題1.0がクローズされた場合

それを行う正しい方法はどれですか?そして、正しい方法で、私は業界で現在使用されているものを意味します。



1
また、次のリリースにも3つの問題すべてを含めることができます。
ピーターズ

はい、私はすでに:) 3つの問題は、次のリリースに予定されているSemVerとALLを使用しています
アーメド

混乱を避けるために質問を編集しました。
アーメド

回答:


14

私は仕事でそれをどうやってやるか教えてくれます。

バージョン管理されたパッケージをビルド、テスト、タグ付け、出力する継続的統合サーバーがあります。前のステージが%100成功した場合にのみ、次のステージに進みます。

バージョンは次のようになります。 <メジャーバージョン>。<マイナーバージョン>。<ビルド番号>

  • バグ修正や機能拡張が完了していないビルドが成功すると、ビルド番号が増加します。
  • バグ修正または機能強化が完了したビルドが成功すると、マイナーバージョンが増加します。これは、特定の形式を使用したコミットメッセージの存在によって自動的に検出されます。このコミットメッセージは、プロジェクトChangeLogにも自動的に取り込まれます。
  • 下位互換性のない変更、ゼロからの書き換え、またはケースバイケースで行われたその他の理由がある場合、メジャーバージョンの増分はすべて手作業で行われます。

ただし、<マイナーバージョン>(たとえば、1.0.0)で一連の機能拡張を完了する必要がある場合。「OK!これはバージョン1.0.0です」と言うためにこれらのすべての拡張を行う必要がありますか、または最初の拡張が完了したらすぐにバージョン1.0.0に増分しますか?
アーメド

@ahmed 1.4.2「この修正セット、およびその時点で準備ができている他のすべて」というアプローチを見てきました... 1.4.2「これは準備が整ったこの日付でリリースされます」とも見ました。リリースサイクルによって異なります。

5
@ahmed 0.xxから1.xxに移行するための基準が設定された機能/修正の完了である場合、それらがすべて完了した後にのみ増分します。注:この方法ではまったく機能しません。バージョンを対象とせず、どの修正を適用するかを決定しません。修正を対象としています。私たちが取得するバージョンは、単に追跡と識別を目的としたものではありません。
-Dietbuddha

これはまさに私が知りたかったことです:)
アーメド

21

バージョン番号は、外部ユーザーがソフトウェアの特定のビルドを識別する方法であるため、リリースにのみ関連します。開発を行うのに忙しく、各修正を個別にリリースしない場合は、修正ごとにリリース番号を増やすことを心配しないでください。外部ユーザーとは無関係であり、余分なバージョンの簿記であなた自身の時間を無駄にします。


これは、リリースがマイナーバグの単純な修正プログラムになるWeb開発にも適用されますか?
アーメド

4
ホットフィックスを発行する前にQAを行いますか?リリースです。製品全体ではない場合、修正プログラムの場合。
ピーターK.

@ahmedこのようなシナリオでは、多くの場合、バージョン番号はユーザーには見えないため意味がありません(リリース番号は主にマーケティングおよび技術サポート用に存在し、どちらも多くのWebアプリには適用されません)。コミットIDを使用するだけで十分な場合があります。バージョン番号の使用を主張する場合は、はい、おそらくパッチレベルを増やします。
アモン

私はここで多くのことを学んでいます:pだから、要約すると:すべてのユーザーがとにかく最後のバージョンを使用するので、コミットIDで十分なので、バージョン番号は必要ありません。
アーメド

2
すべてのユーザーは同じバージョンを使用していますが、欠陥レポートを調べるまでに、バージョンは移行されています。それでも、レポートをソフトウェアの特定のビルドに関連付ける方法が必要です(日付/時刻で十分な場合があります)。
mattnz

2

継続的にデプロイされるWebアプリケーションの場合、前もってsymverとビルド番号のテーリングを使用してビルド番号を作成する傾向があります。つまり、2.5.3.4328の場合、4328は継続的な統合システムに由来します。一般的な予想は、数字は意図的な手順によって変化するが、ビルド番号は真の一意のIDであるということです。

ここで行っているように見えるのは、展開の日と関連するsvnビルド番号をキャプチャすることです:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

それが価値があるもののために。


0

他の答えはすでに素晴らしいので、それらの上にだけ追加します。ソフトウェアがリリースされておらず、パブリックバージョン管理が本当に必要ない場合(非パブリックバージョン管理はVCSです)、バージョンの最後にキーワード「SNAPSHOT」を追加します。一部のシステム、特に依存関係管理では、バージョン番号ではなくスナップショットの変更日を比較するという点で、リリースされたバージョンとは異なる方法でスナップショットを扱います。したがって、パッケージリポジトリに午前8時からのv。1.0.0 -SNAPSHOTがあり、ローカル依存関係ダウンローダーが午前7時から同じバージョンを持っている場合、リポジトリから更新されたバージョンをダウンロードする必要があります。

上記のように、プライベートバージョン管理はバージョン管理システム(git、svnなど)によって提供されます。


0

バージョン管理の理論については、もう1つの視点があります。

バージョン1.0.0にいつ増やすべきですか?

メジャーバージョン番号の変更に焦点を当てます。

私の答えは、基本的に準備ができたらです。0.9から1.0に移行するのは大きなことです。なぜなら、あなたはベータ製品から公式リリースに移行するという一般の認識になるからです。

(私はここでそれが会社からの商業製品であると仮定するつもりです)。

0.9から1.0に移行する前のいくつかの質問。

組織には、現在のすべてのクライアントに通知する時間がありますか。パーティーを開く。多くのサポートリクエストを受け取ります。製品を販売するアカウントマネージャーですか?などなど

はい、私はバージョニングをマーケティングツールとして見ています。あなたが周りを見れば、それが基本的に業界標準であることがわかります。

当社はバージョン2.xから3.0に移行し、素晴らしいパーティーを開き、多くの話題を巻き起こしました。そのため、かなりの数の新しいクライアントがいました。いくつかのインターフェースの更新は別として、バージョン間の違いはごくわずかでした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.