問題タブ [versioning]

私は新しいシステムを設計しており、システムとともに成長する多くのインターフェースを持っています。このインターフェイスに名前を付けるベスト プラクティスは何ですか

そして私はこれをします

次に、方法2を追加する必要があるので、今何をしますか?

または同じ他の方法ですか？

アセンブリ A と B は非公開で展開され、厳密な名前が付けられています。アセンブリ A には、アセンブリ B への参照が含まれています。アセンブリ B には、B1 と B2 の 2 つのバージョンがあります。アセンブリ A が B1 または B2 のいずれかにバインドされる可能性があることを示すことができるようにしたいと考えています。理想的には、この情報をアセンブリ自体に組み込むことによってです。私のオプションは何ですか？

バージョン管理ポリシーと、それが GAC に適用される方法についてはある程度知っていますが、これらのアセンブリが GAC にあることに依存したくありません。

次の形式のバージョン番号があります。

version.release.modification

ここで、バージョン、リリース、および変更は、数字のセットまたは「*」ワイルドカード文字のいずれかです。さらに、これらの番号のいずれか（および先行する。）が欠落している可能性があります。

したがって、以下は有効であり、次のように解析されます。

ただし、これらは無効です。

リリース、バージョン、および変更番号を検証および取得するための、それほど複雑ではない正規表現を誰かが私に提供できますか？

私はこれを理解しようと非常に多くの時間を費やしてきました。これは最も単純なことであり、Javaアプリケーションをjarで配布するすべての人がそれに対処する必要があります。

Javaアプリにバージョニングを追加して、テスト時にバージョン情報にアクセスできるようにする適切な方法を知りたいだけです。たとえば、Eclipseでのデバッグやjarからの実行などです。

これが私のbuild.xmlにあるものです：

これにより/META-INF/MANIFEST.MFが作成され、Eclipseでデバッグしているときに値を読み取ることができます。

}

ただし、jarファイルを作成すると、別のjarのマニフェストが読み込まれます（おそらく、アプリケーションによって読み込まれる最初のjar-私の場合はactivation.jar）。

また、マニフェストファイルにはすべての適切な値が含まれていますが、次のコードも機能しません。

何か案は？

#define ディレクティブにバージョン番号を含むヘッダー ファイルを含む C++ プロジェクト (VS2005) があります。ここで、ツイン C# プロジェクトにまったく同じ番号を含める必要があります。それを行う最良の方法は何ですか？

このファイルをリソースとして含め、実行時に正規表現で解析してバージョン番号を回復することを考えていますが、もっと良い方法があると思いますか?

バージョンを .h ファイルの外に移動することはできません。また、ビルド システムはそれに依存しており、C# プロジェクトは適合させる必要があります。

アプリの新しいバージョンをライブでプッシュするときに、リリースリビジョン番号を表示する方法を教えてください。

ファイルで使用$Rev$して最新のリビジョンを取得できますが、ファイルを更新した後でのみ使用できます。

リポジトリ/ディレクトリ内のファイルを変更するたびに1つのファイルの文字列を更新したい場合はどうなりますか？

方法はありますか？

コードを保持し、複数のマシンでバージョン管理するために人々がどのような戦略を持っているかを知りたいです。たとえば、XP を実行するデスクトップ PC、OSX を実行する Macbook、XP を実行する VMWare、および製品のデモを実行するためのセールス ラップトップがあります。これらを常に同期させる方法を知りたいです。Subversion はこれの可能性がありますが、バイナリ ファイルを処理するのにはあまり役に立ちません。ここで何かを見落としている可能性があります。同様の問題を抱えているに違いないので、他の人は何を使用していますか? すべてのファイルを USB ドライブに保存し、ローカル ファイル システムには保存しませんか。私は常にオンラインであるとは限らないため、リモート ストレージは実際にはオプションではありません。

次の条件の単純なビジネス ワークフローがあります。

1. ユーザーはdesingerを使用してワークフロー自体を変更する必要があります
2. ワークフローは長いリンニングワークフローなので、連載されます

さまざまなワークフロー アセンブリのバージョン管理タスクを自動化する方法はありますか?

私の質問は、どのタイプのプロジェクトにどのバージョン命名スキームを使用する必要があるかということです。

非常に一般的なのは major.minor.fix ですが、これでも数字が 4 になることがあります (つまり、Firefox 2.0.0.16)。一部のモデルでは、奇数が開発者バージョン、偶数が安定版リリースを示します。また、-dev3、-rc1、SP2 など、あらゆる種類の追加機能が混在する可能性があります。

あるスキームを別のスキームより優先する理由はありますか? また、異なるタイプのプロジェクト (つまり、オープン ソースとクローズド ソース) には異なるバージョン命名スキームを使用する必要がありますか?

(データベース スキーマのバージョン管理とは関係ありません)

多くの場合、データベースとやり取りするアプリケーションには、多くのテーブルのデータで構成されるドメイン オブジェクトがあります。アプリケーションが、CVS の意味で、これらのドメイン オブジェクトのバージョン管理をサポートするとします。

任意のドメイン オブジェクトについて、この要件を処理するデータベース スキーマをどのように設計しますか? 共有する経験はありますか？