問題タブ [versioning]

私は現在、他の 5 人の開発者と一緒にプロジェクトに取り組んでおり、バージョン管理システムに Subversion を使用しています。ソフトウェアの最初のリリースまでに 12 のマイルストーンがあることを確認しました。バージョン番号 (0.1 から 0.12) と説明的なラベルを使用して、マイルストーンにラベルを付けました。例えば：

• 0.1 - ナビゲーション
• 0.2 - 検索中
• 0.3 - ユーザー管理

ただし、いくつかのマイルストーンごとに、以前のマイルストーンで構成される外部リリースがあります。したがって、次のような結果になります。

• 0.1 - ナビゲーション
• 0.2 - 検索中
• 0.3 - ユーザー管理
• 0.4 - アルファ 1

これらの各マイルストーンは並行して開発できますが、並行して QA も行う必要があります。これは、マイルストーンのバージョン番号だけでラベル付けされた各マイルストーンの Subversion にブランチを作成することで実現しています。自動化されたシステムが各マイルストーンを個別に構築し、マイルストーン番号とアプリケーションの構築元であるサブバージョン リビジョン番号を使用してアプリケーションをバージョン管理します。バージョン番号はアプリケーション内で目立つように表示されるため、QA チームはバージョン番号を見て、それを特定のマイルストーンに関連付け、QA が必要なものとそうでないものを知ることができます。マイルストーンが QA に合格すると、トランクにマージされ、進行中の開発は最新のコードで更新されます。

ただし、バージョン番号の増加には以前のすべてのバージョンが含まれるという仮定があります (当然のことです)。残念ながら、上記のスキームでは、あるマイルストーンが別のマイルストーンより先に終了する可能性があるため、これは発生しない可能性があります。たとえば、0.3 は 0.1 より前に終了する可能性があります。つまり、0.2 または 0.1 の機能を含まない 0.3 の内部リリースがあるということです。

これは私の問題です。複数の並行リリース (内部またはその他) が非連続的に完了する可能性がある場合、ソフトウェアをインテリジェントにバージョン管理するにはどうすればよいですか?

弊社の状況は以下の通りですが、どのような状況でもこの問題が気になります。

私たちは4つのプロジェクトからなるフレームワークを持っています:

• 豆
• ユーティリティ
• フレームワーク
• ウェブ

バージョンを必要とし、Bean と util のバージョンに依存するモジュールもあります。

最後に、コア プロジェクトの特定のバージョンと 1 つ以上のモジュールで構成される顧客プロジェクトがあります。

これらのプロジェクトをバージョン管理する標準的な方法はありますか?

リリースを QA に提出し、リリースのメンテナンス (リリース = タグと可能性のあるブランチ) を使用して進行中の開発を管理しようとすると、私には単純に思えますが、非常に複雑になっています。

私は次のようなものを好みます：

1.2.0 - メジャー バージョンとマイナー バージョン + リリース。

1.2.1 - 次のリリース

1.2.0_01 - 1.2.0 リリース (ブランチ) のバグ修正

等

何か案は？

バージョン番号を比較するための標準的なイディオムはありますか? ポイントリリースの最大数がまだわからないため、単純な String compareTo を使用することはできません。バージョンを比較し、次のことが当てはまるようにする必要があります。

アセンブリの命名とバージョン管理に関するいくつかの優れたプラクティスを探しています。メジャー バージョンまたはマイナー バージョンをどのくらいの頻度でインクリメントしますか?

場合によっては、リリースがバージョン 1.0 から 3.0 に直行するのを見てきました。それ以外の場合は、バージョン 1.0.2.xxxx のままになっているようです。

これは、会社全体の複数のプロジェクトで使用される共有アセンブリ用です。良いインプットを期待しています。

明確にする必要がある 2 つのシナリオがあります。

1. .NET 3.5 でコンパイルされた実行可能ファイルは、.NET 1.1 でコンパイルされたライブラリを使用する必要があり、ライブラリは 1.1 ランタイムで実行する必要があります。

2. .NET 1.1 でコンパイルされた実行可能ファイルは、.NET 3.5 でコンパイルされたライブラリを使用する必要があります。

.NET ランタイムの 2 つのバージョンをロードすることは不可能であり、Microsoft のドキュメントはこの問題について非常に曖昧であると述べている信頼できる情報源を見つけることができません。

A がアセンブリ B 1.1 と C を参照し、C が B 1.2 を参照している場合、アセンブリの競合をどのように回避しますか?

私は、C の参照がカプセル化され、問題が発生しないと思っていましたが、すべての dll が問題が発生するビンにコピーされているようです。

これを回避する2つの方法は、GACまたはアセンブリバインディングを使用することだと理解していますか? GAC は私にとって最善のアプローチとは思えません。dll がそこにあると仮定するのは好きではないため、ソリューションの lib ディレクトリから dll を参照することを好みます。

アセンブリ バインディングは堅牢ではないように思えますが、アセンブリの 1 つのバージョンが他のバージョンにはない機能を持っている場合、問題は発生しませんか?

私の場合、サードパーティのdllを使用しているため、自分で使用しているよりも古いバージョンのnHibernateを使用しています。

WCFを変更した場合、サービスにアクセスしているすべてのクライアントコンピューターで何らかの更新を実行する必要がありますか？（つまり、svutils.exeを実行し、すべてのapp.configなどを更新しますか？）

現在、ショップの製品全体をパッケージ化するためのリリース プロセスの自動化/改善に取り組んでいます。現在、製品は次の組み合わせです。

• Java サーバー側コードベース
• XML 構成およびアプリケーション ファイル
• 管理者向けのシェルおよびバッチ スクリプト
• 静的に提供される HTML ページ
• 他にもいくつかありますが、それがほとんどです

それらのすべてまたはほとんどには、さまざまな目的で使用されるさまざまなバージョン情報が含まれています。リリース パッケージ プロセスの一部には、情報を更新するために (スクリプトで) 検索、grep および sed を多数実行することが含まれます。製品をパッケージ化するこの接着剤は、有機的でジャストインタイムの方法で一緒に石畳になっているようで、維持するのはかなりひどい. たとえば、一部の Java メソッドは、リリース時の Date オブジェクトを作成します。その引数は、コンパイラの検証なしで、テキストの置換によって更新されます。

「xyzの機能を使用してこれを行う」ことを避け、一般的な慣行に集中したいので、実際に使用されているソフトウェア（CVS、SVN、antなど）の例を挙げないようにしています。問題の原因を粗悪な設計のせいにしたいのですが、さまざまなテクノロジを使用してやり直す必要がある場合、慣習を定める以外に、これを処理する最善の方法がわからないでしょう。

私の質問は、さまざまなテクノロジ、ファイルタイプ、プラットフォーム、およびバージョン管理システム間でバージョン管理情報を維持および更新するためのベスト プラクティスまたはヒントやヒントはありますか?

Linux上に（別の共有ライブラリを介して）依存関係の1つとしてロードするlibfoo.so.1（つまり）実行可能ファイルがあります。SONAMEまた、別のシステムライブラリにリンクし、システムライブラリはシステムバージョンにリンクしますlibfoo.so.2。その結果、との両方が 実行中に読み込まれ、バージョン1のライブラリから関数を呼び出すはずだったコードは、バージョン2の新しいシステムライブラリから（バイナリ非互換の）関数を呼び出すことになります。これは、一部のシンボルが同じままであるためです。その結果、通常、スタックスマッシングとそれに続くセグメンテーションフォールトが発生します。libfoo.so.1libfoo.so.2

現在、古いバージョンに対してリンクしているライブラリはクローズドソースのサードパーティライブラリであり、どのバージョンlibfooに対してコンパイルするかを制御することはできません。と仮定すると、残っている他の唯一のオプションは、現在リンクしているシステムライブラリの束を再構築しlibfoo.so.2てリンクすることlibfoo.so.1です。

古いものにリンクするローカルコピーでシステムライブラリを置き換えることを回避する方法はありますlibfooか？両方のライブラリをロードして、正しいバージョンのシンボルを呼び出すコードを作成できますか？だから私はいくつかの特別なシンボルレベルのバージョン管理が必要ですか？

Maven リリース プラグインを使用して、スナップショット プロジェクト 'foo-1.0-SNAPSHOT' をリリースしたいと考えています。このプロジェクトは、まだリリースされていないサードパーティ モジュール「bar-1.0-SNAPSHOT」に依存しています。プロジェクトの pom.xml でオプション 'allowTimestampedSnapshots' を使用して、タイムスタンプ付きのスナップショットを許可していますが、maven が未解決の SNAPSHOT 依存関係について文句を言うので、自分でビルドしない限り、サードパーティ モジュール (バー) にはタイムスタンプが付けられないと想定しています。

依存する SNAPSHOT プロジェクトに関係なく、プロジェクト foo をリリースする方法はありますか?