問題タブ [version-numbering]

スクリプトを使用して Visual Studio プロジェクトを構築するのはまったく初めてなので、プロセスに関する私の理解が間違っていると思われる場合は、遠慮なく修正してください。

Wpf.exe プロジェクトといくつかのクラス ライブラリ プロジェクトで構成されるビジュアル スタジオ ソリューションがあります。

.sln現在、以下のスクリプトを使用してファイルを正常に構築しています

"%VS_IDE_DIR%devenv.com" "...Solution-File-Path.sln" /rebuild Release /useenv

現在、Wpf.exeファイルはWpf プロジェクトのプロパティで 指定さFile VersionれProduct Version 1.0.0.0ているデフォルトの を取得します。Publish -> Publish Version

どういうわけか、スクリプトを介してFile Versionandを設定したいと思います。Product Versionどうすればそれを達成できますか？

基本的environment variableにProduct Version、File Version製品バージョンとファイル バージョンの値を環境変数と同じに設定したいと考えています。

バージョン管理とは非常に紛らわしいです。多くのバージョン管理のサンプルを見ました。それらのいくつかには、転覆情報も含まれています。それらの多くは大丈夫に見えます。

• 0.5
• 0.1.0
• 0.0.1.0
• 5.5.5.2_R139
• ...

ソフトウェアのバージョン管理のベスト プラクティス/ベストな方法は何ですか?

現在、バージョン番号を更新しようとしています。バージョン番号を含むNantビルドファイルを使用してTeamCityで。私がちょうど使用する場合

スクリプトでは、buildNumber は 2.16.3 に更新されていますが、このバージョン番号にもカウンターが必要です。したい意味

しかし、これはうまくいきません。これを行う方法を知っている人はいますか?私のため ？

アップデート

{0} を Teamcity のビルド番号として使用し、そのビルド番号をファイル内の自分のビルド番号に追加して実装を行いました

アプリのバージョン番号を自動入力したい plist があります。これは可能ですか? もしそうなら、誰かが私にどのように教えてもらえますか？

autotoolsを使用して共有ライブラリを構築するレガシーコードがあります。これらのライブラリはAndroidアプリケーションで使用する必要があるため、単純なJavaクラスとそのJNIラッパーを（共有.soライブラリとして）作成しました。

レガシービルドシステムを適切に実行し、JavaプログラムのネイティブライブラリをビルドしてリンクするAndroid.mkスクリプトをすでに持っています。

出力ファイルは次のとおりです。

lib-wrapper.solib-aライブラリとの両方に依存しますlib-b。従来のautotoolsセットアップは、共有ライブラリファイル名にバージョン番号を追加することに注意してください。これは、依存関係としてに埋め込まれていlib-wrapper.soます。

問題：

APKのビルド中（たとえば、Eclipseから署名されていないパッケージをエクスポートする）、ファイル名からバージョン番号
が削除されます。これにより、エラーが発生します。

ライブラリを読み込めません：link_image [1721]：30は必要なライブラリ'lib-b.so.2'を'lib-wrapper.so'に読み込めませんでした

APKにはファイルが含まれているためですlib-b.so。

APKのビルド中にバージョン番号を強制的に保持するにはどうすればよいですか？

x86ライブラリ/execのビルドに同じセットアップが使用されるため、レガシービルドシステムを変更することは（必須になるまで）かなり不可能です。

ありがとうございました。

しばらくの間ネットを掘り下げていたので（もちろんstackoverflowも含まれています）、結果が得られなかったので、ここで何か間違ったことをしていると感じています。

簡単に言えば、正常に動作し、バージョンを正しくインクリメントし、SVN のコードをチェックインし、タグを付けて問題なくデプロイする Maven リリース プラグインを使用して Maven プロジェクトをセットアップしました。

ただし、生成されたjarを参照する必要があるリリースごとにスクリプトも生成する必要があります。これは次の 2 つのことを意味します。

1. リリース バージョンの場合は、スクリプトを変更してリリース バージョンを含め、SVN にコミットし直します (タグ付けされるなど)。
2. リリースに続いて、(次の) SNAPSHOT バージョンを含むようにスクリプトを更新し、SVN にコミットする必要があります。

たとえば、pom の現在の作業バージョンが 1.1.1-SNAPSHOT であるとします。そのため、私の script.sh には project-1.1.1-SNAPSHOT.jar への参照が含まれています。mvn release:prepare を実行すると (maven-release-plugin によって提案されたバージョンに固執すると仮定して)、リリース バージョンは 1.1.1 になります。この段階で、script.sh を project-1.1.1.jar を参照するように変更し、再度コミットする必要があります。 pom は 1.1.2-SNAPSHOT に変更され、SVN にコミットされます。この時点で、project-1.1.2-SNAPSHOT.jar を参照するようにスクリプトを変更する必要があります。

GMavenプラグインのようなものを使用してスクリプトを簡単に変更できることがわかりました-そして、実際にはリソースの準備段階でスクリプトを開始する必要があります（おそらく別のものを見る必要がありますか？）しかし、私が最大の問題see は、maven-release-plugin が使用することを決定したバージョンを取得しています。

• maven-release-plugin が使用することを決定したリリース バージョン
• maven-release-plugin が使用する次の dev/SNAPSHOT バージョン

これらにアクセスできたら、GMaven に必要なコードを実行させて、それに応じてスクリプトを変更できると思います。(ただし、上記のシナリオを見て、これを行うためのより良い方法をお勧めできる場合は、それを聞いてうれしいです!) ${project.releaseVersion} のようなプロパティはありますか (ところで、それは機能しません)これら2つのバージョン番号を教えてくれるのはどれですか?

前もって感謝します！

リヴ

提供された API アセンブリを参照するときにサード パーティが拡張できる .Net システムがあります。私の懸念は下位互換性に関するものです。つまり、提供された API アセンブリにバイナリの互換性を損なわない変更が加えられるたびに (メソッドが追加されるなど)、次のことを確認する必要があります。

1. 古いバージョンを使用して構築されたプラグインは、新しいバージョンを実行しても機能するはずです。
2. ただし、新しいバージョンを使用して構築されたプラグインは、古いバージョンを実行している場合は機能しないはずです (そうしないと、プラグインが存在しないメソッドを呼び出そうとすると、ランタイム エラーが発生する可能性があります)。

2 番目の要件のため、単純にバージョン番号を同じに保つことはできません。要件 1 を満たす唯一の方法は、すべての API アセンブリの以前のすべてのバージョン番号の長いリストを維持する必要があるバインディング リダイレクトを使用することです。これはエラーが発生しやすく、退屈なようです。

.Net アセンブリのバージョン番号を扱う際に適切な下位互換性を維持するための代替戦略はありますか?

私は2、3か月間git flowを使用していて、非常にうまく機能しています。「バンプバージョン」の操作を自動化したいのですが。

プロジェクトはPHPであり、footer.phpには現在のリリースタグに置き換えるトークンがあります。gitログとPHPファイルを少し調整すれば、すべてうまくいくはずですが、誰かが以前にこれを行ったことがあると思います...

何か案は？

ここで説明されているプロジェクトと同様のプロジェクトで作業してい ます。そのため、親の pom.xml にいくつかのモジュールがあります。

これらのモジュールには、一般的なバージョン番号があります (例:1.0.0-SNAPSHOTまたはなし) -SNAPSHOT。feature.xml ファイルには、同じバージョン番号が含まれている必要があります。

と：

ファイル category.xml (p2 update-site プロジェクト内) と MANIFEST.MF (プラグイン プロジェクト内) には、同じ値が含まれている必要があります。

問題は、Maven を使用してこれらすべてのファイルのバージョン番号の更新プロセスを自動化する方法です。

maven-release-plugin と maven-versions-plugin を使用して、この問題を解決しようとしました。最初のプラグインは、多くの未使用のアクションを作成します (このプロジェクトでは使用しない多くの CVS コミットを作成するなど)。2 番目のプラグインは、pom.xml ファイルのみを変更し、feature.xml、category.xml、および MANIFEST.MF を変更しません。