私は現在、会社で官僚的な地獄に陥っており、テスト プログラムに対するさまざまなレベルのソフトウェア変更を構成するものを定義する必要があります。私たちは内部的に従う大まかな慣行を持っていますが、品質システムで参照する標準 (存在する場合) を探しています。システムは開発者によって大きく異なる可能性があることは認識していますが、最終的には、主要な変更、マイナーな変更などを構成するものについての「ベスト プラクティス」ガイドを探しています。可能であれば、ISO の目的。
私の会社で開発されたソフトウェアが半導体のテスト自動化のために社内で使用されていることを明確にするため。私たちはこのコードを販売しておらず、バージョン管理は実際には記録保持のみを目的としています。xyz の変更を使用して、リリースに必要なサインオフと承認のレベルを実現しています。
3 つのレベルのリビジョン番号を使用することをお勧めします。
xyz
x はメジャーです y はマイナーです z はバグ修正です
重要なことは、同じ x を持つ 2 つの異なるソフトウェア バージョンには、バイナリ互換性があることです。y が他よりも大きいが、同じ x が機能を追加する可能性はあるが、機能を削除しないソフトウェア バージョン。これにより、同じメジャー番号内での移植性が保証されます。そして最後に、z はバグ修正以外の機能的な動作を変更してはなりません。
編集：
使用されているリビジョン番号スキームへのリンクを次に示します。
xyz 形式にビルド番号を追加します。
xyzbuild
x = 主要な機能の変更
y = マイナーな機能の変更
z = バグ修正のみ
build = コードがコンパイルされるたびに増加
ビルド番号を含めることは、人々が自分のバイナリに特定の変更が含まれているかどうかを把握しようとする内部目的にとって重要です。
@lewapが言ったことを拡大するには、使用します
xyz
z レベルの変更は、ほぼ完全にバグ修正であり、インターフェースの変更や外部システムの関与はありません。
ここで、y レベルの変更により機能が追加され、UI/API インターフェイスが変更される可能性があるほか、外部システムが関与する可能性があるより深刻なバグが修正される可能性があります
ここで、x レベルの変更には、完全な書き直し/再設計から、データベース構造の変更 (つまり、Oracle から SQLServer への変更) までのすべてが含まれます。つまり、「ポート」または「変換」を必要とする変更のドロップではないすべてのことです。 " 処理する
内部ソフトウェアと外部ソフトウェア (製品) に取り組んでいる場合、異なる可能性があると思います。
内部ソフトウェアの場合、正式に定義されたスキームを使用しても問題になることはほとんどありません。ただし、製品の場合、バージョンまたはリリース番号はほとんどの場合、技術的または機能的な基準を反映していない商業上の決定です。
当社では、xyz 番号付けスキームの xy は、マーケティングの少年少女によって決定されます。z と内部ビルド番号は、R&D 部門によって決定され、リビジョン管理システムに遡って追跡され、それが作成されたスプリントに関連しています (スプリントは反復を表すスクラム用語です)。
さらに、バージョンとリリースの間である程度の互換性を正式に定義すると、非常に急速に上に移動するか、ほとんど移動しない可能性があります。これは、追加された機能を反映していない可能性があります。
以前に同様の質問への回答で述べたように、使用されている用語はあまり正確ではありません。関連する 5 つのディメンションについて説明した記事があります。ソフトウェア開発用のデータ管理ツールは、3 つ以上のツールを同時に一貫してサポートする傾向にありません。5 つすべてをサポートしたい場合は、開発プロセスを記述する必要があります。
Peter van den Hamer and Kees Lepoeter (1996) 設計データの管理: CAD フレームワーク、構成管理、および製品データ管理の 5 つの次元、IEEE 議事録、Vol. 84、No.1、1996 年 1 月
これを同僚に説明するための最善の方法は、有名で成功しているソフトウェア パッケージから引き出された例と、それらのメジャー リリースとマイナー リリースへのアプローチ方法によるものだと思います。
最初に言うことは、リリースのメジャー.マイナー ドット表記は比較的最近の発明だということです。たとえば、UNIX のほとんどのリリースには、実際にはバージョン番号ではなく名前 (無意味な番号が含まれることもありました) がありました。
しかし、major.minor、ナンバリングを使用したい場合、メジャー番号は基本的に以前の多くのバージョンと互換性がないことを示します。Windows 2,0 から 3.0 への変更を考えてみましょう。ほとんどの 2,0 アプリケーションは、Windows 3,0 の新しいオーバーラップ ウィンドウに適合しませんでした。包括的ではないアプリの場合、ファイル形式の根本的な変更 (たとえば) は、メジャー バージョンの変更の理由になる可能性があります。
メジャー バージョン番号が変更されるもう 1 つの理由は、ユーザーが違いに気付くことです。繰り返しますが、これは Windows 2.0 から 3.0 への変更に当てはまり、後者の成功の原因となりました。アプリの外観が大きく異なる場合、それは大きな変更です。
マイナー バージョン番号の場合、これは通常、実際には非常にメジャーであるが、ユーザーには気付かれない変更を示すために使用されます。たとえば、Win 3.0 と Win 3.1 の内部的な違いは実際には非常に大きなものでしたが、インターフェイスは同じままでした。
3 番目のバージョン番号については、それが本当に意味することを知っている人はほとんどおらず、あまり気にしていません。たとえば、私は毎日の仕事で GNU C++ コンパイラ バージョン 3.4.5 を使用しています - これは 3.4.4 とどう違うのですか - 私には手がかりがありません!