ソフトウェアのバージョンを管理/制御する方法は？
私の会社のいくつかの既存のソフトウェアパーツのバージョン管理の概要を作成する問題に直面しています。今まで誰も-開発者に期待-異なるバージョンがあることを知っていません。それが概要の理由です。実際、私は将来のバージョン管理を設定し、これらすべてを私たちの管理者と通信することになっています...
したがって、問題はそのようなアウトラインを作成する方法です。ソフトウェアのバージョン管理を簡単にするための原則、またはすべてのバージョンをマップして互換性を保つための優れたプログラムはありますか？
また、ソフトウェアのバージョンを管理するための一般的な優れたアプローチはありますか？
セマンティックバージョニング を確認してください。
ソフトウェア管理の世界には、「依存関係の地獄」と呼ばれる恐ろしい場所があります。システムが大きくなればなるほど、そしてソフトウェアに統合するパッケージが増えるほど、この絶望の穴の中で自分を見つける可能性が高まります。
多くの依存関係があるシステムでは、新しいパッケージバージョンのリリースはすぐに悪夢になります。依存関係の仕様が厳しすぎると、バージョンロック（すべての依存パッケージの新しいバージョンをリリースしなければパッケージをアップグレードできない）の危険があります。依存関係があまりにも緩く指定されている場合、バージョンの乱雑さによって必然的に噛まれるでしょう（合理的よりも多くの将来のバージョンとの互換性を想定します）。依存関係の地獄とは、バージョンロックやバージョンの乱雑さにより、プロジェクトを簡単かつ安全に進めることができない場合です。
この問題の解決策として、バージョン番号の割り当て方法とインクリメント方法を規定する簡単なルールと要件のセットを提案します...
このシステムを「セマンティックバージョニング」と呼びます。このスキームでは、バージョン番号とその変更方法は、基礎となるコードの意味と、あるバージョンから次のバージョンに変更されたものを伝えます。
このルールはわかりませんが、多くの場合、バージョンは2〜4の数字で構成されています。
1.2.3.4のようなバージョンは、次のように解釈できます。
- 1-メジャーバージョン、変更すると互換性が失われます
- 2-マイナーバージョン、新機能
- 3-バグ修正バージョン、リリースにバグ修正が含まれている場合のみ
- 4-ビルド番号、通常は自動ビルドシステムまたは継続的インテグレーションシステムによって決定されるビルドの内部番号。
すでに述べたように、これは多くの一般的な解決策の1つにすぎず、私が好む解決策です。
まだやっていない場合は、バージョン管理ソフトウェアを使用する必要があります。 Fossilには、分岐とマージの組み込みの表示があります。現在、GitとMercurialは人気がありますが、Subversionはずっと以前から人気があるかもしれません。ソフトウェアの履歴からグラフィックを作成して分析を実行できるGitのプラグインはあると思います。
ソフトウェアを初めてソース管理に入れるときは、メジャーリリースの履歴を再作成する必要があるでしょう。おそらく（うまくいけば、「神よ、お願い」のように）彼らは各メジャーリリースのソースのZipファイルを持っています。これらを解凍し、含まれているファイルを時系列順にソース管理にチェックインします。次に、ブランチとマージの歴史と、GitまたはMercurialへのプラグインを使用してきれいなグラフィックスを生成できる主要な機能があります。
最初のチェックインを本当に正しく行うには、数回の試行が必要な場合があります。ソース管理なしで複数の開発者が作業しているとは思えません。現在何を使用していますか？