問題タブ [semantic-versioning]

この質問が間違った場所に投稿されている場合はお詫び申し上げます。

私は変更を加えているパブリック nuget パッケージ ( EnumStringValues ... プラグ、プラグ プラグ) を持っています。

この変更によって API シグネチャが変更されることはありません - 古いコードは引き続きコンパイルされます。ただし、エッジ ケースでの動作は変更されます - ほとんどの場合、以前は例外を生成していた使用法が別のデフォルト動作を実行するようになります。TryParse() 呼び出しもあり、(このエッジ ケースでは) (例外ではない) 失敗ケースを成功ケースに変更します。

エッジケースは、「このライブラリを実際に使用することを意図していない方法で使用した」です。つまり、ライブラリの使用範囲を少し広げました。

それは重大な変更ですか？したがって、新しいメジャーバージョンが必要ですか? それとも、「下位互換性」のあるマイナーな変更にすぎませんか。

私の最初の直感は、これは既存の呼び出しの動作に対する変更であり、したがって重大な変更であると言うものです。考え？

この質問は、C や Java などの 1 つの言語 (「ソース」) で記述され、動的リンクを使用してマシン コードや Java バイト コードなどの別の言語 (「バイナリ」) で配布されるすべての言語に適用されます。

ユーザーが既に私のライブラリのバージョン A を使用しているとします。新しいバージョン B をリリースします。

B に対して変更せずにコードをコンパイルし、B で正しく実行できる場合、A から B への変更はソース互換性があると言われます。

A に対してコードをコンパイルし、B で正しく実行できる場合、A から B への変更はバイナリ互換性があると言われます。この状況は、分離されたモジュールのロード (OSGI など) なしで推移的な依存関係グラフを使用する場合によく見られます。X は Y および Z の特定のバージョンに対してコンパイルされ、Y は別の特定のバージョンの Z に対してコンパイルされます。実行時に、Y の Z への呼び出しは正しくない可能性があり、クラッシュする可能性があります。

変更がソース互換であっても、バイナリ互換でない可能性があります。変更がソース互換性がなく、バイナリ互換性がある可能性もあります。

セマンティック バージョニングにはどの互換性を使用しますか? メジャー アップデートとマイナー/パッチ アップデートを区別するためにソース互換性を使用しますか? または、メジャー アップデートとマイナー/パッチ アップデートを区別するためにバイナリ互換性を使用しますか?

私の現在の動機は、Scala ライブラリです。Scala バイナリ互換性は分析が非常に難しく、コンパイラの詳細をよく理解している必要があります。ソースの互換性とバイナリの非互換性は非常に一般的です。

これは奇妙なエッジ ケースではありません。この問題は、ほとんどすべてのコンパイル済みの動的にリンクされた言語で発生する可能性があります。

Devise宝石を使用しているとしましょう。Gemfile で使用する必要があるのは、次のうちどのバージョンですか。

'devise', '~> 3.5.1'

また

'devise', '~> 3.5'

どちらか一方を使用することの長所と短所は何ですか?

RubyGems によると:

小さなバグ修正など、実装レベルの詳細変更のための PATCH 0.0.x レベルの変更

新しい機能/機能など、下位互換性のある API の変更のための MINOR 0.x.0 レベルの変更

下位互換性のない API の変更に対する x.0.0 レベルのメジャー変更 (更新すると既存のユーザー コードが壊れる変更など)

'devise', '~> 3.5'実行すると小さなバグ修正が得られるので、使用するのは理にかなっていませんbundle updateか?

私は、build.gradle ファイルをセマンティック バージョンを使用するように変換するイニシアチブの真っ最中です。Gradle の使用に加えて、Git も使用し、Gitflow ワークフローに従っています。Jenkins は、プロジェクトのビルドに使用されます。

リリースされたアーティファクトのバージョンは、MAJOR.MINOR.PATCH 形式に従います。build.gradle ファイルで依存関係を宣言する場合、10.0.+ などの動的バージョンを使用します (つまり、最新の 10.0.PATCH バージョンを使用します)。

アーティファクトを Release Candidates リポジトリから Nexus の Releases リポジトリに昇格させます。リポジトリのポリシーは「リリース」に設定されています。製品の複雑さ (200 以上のプロジェクト、多くのアップストリームとダウンストリームの依存関係がある) のため、Jenkins で利用できるプロモーション プラグインの多くは不十分なようです。アーティファクトの名前を変更し (10.0.0-rc.1-abcdefg は 10.0.0 になります)、正しい Nexus リポジトリにアップロードする方法として、Jenkins にマスター ブランチを構築させることを考えていました。

アップストリームの依存関係でパッチのバージョンが増加している状況を処理する方法がわかりません。ダウンストリーム プロジェクト (WAR) は Jenkins によって再構築され、新しい JAR がバンドルされますが、ダウンストリーム プロジェクトのバージョンは変更されません。Nexus にアップロードしようとすると、同じバージョンを持つことができるアーティファクトは 1 つだけであるため失敗します。

次に例を示します。

• Releases Nexus リポジトリには、10.0.0 でバージョン管理されたアップストリーム API と 10.0.0 でバージョン管理されたダウンストリーム プロジェクトがあります。
• ダウンストリーム プロジェクトはアップストリーム API の 10.0.+ に依存します
• アップストリーム-api.jar は、ダウンストリーム-project.war ファイルにバンドルされています
• 2 つの成果物は、製品のリリース X の一部としてデプロイされます
• ホットフィックス ブランチがマスターにマージされると、upstream-api のバージョンが 10.0.1 に変更されました
• この修正は、デプロイされると、製品が Release X' になることを意味します。
• ダウンストリーム プロジェクトは 10.0.0 のままですが、アップストリームの依存関係の変更により再構築されます
• Jenkins は、downstream-project-10.0.0.war が既に存在するため、Nexus へのアップロードに失敗します

古いアーティファクトを新しいアーティファクトに置き換えることもできますが、その場合、Release X は Nexus のアーティファクトから展開できなくなります (たとえば、ロールバックの場合、または古いリリースの問題を複製する必要がある場合)。

これは通常どのように処理されますか?

posix 環境で semver 値を操作するかなり移植性の高い方法が必要です。

具体的
には、1. ソート、および
2. 指定された semver 値のメジャー、マイナー、パッチのいずれかをインクリメントします。

API の関数の 1 つに次の変更が加えられた場合、セマンティック バージョニングを使用します。

それには新しいメジャー バージョンが必要ですか、それともマイナー バージョンで渡すことができますか?

バージョン管理は、以前のバージョンの .Net とは異なるようです。project.json は、Major.Minor.Patch-Special 形式のセマンティック バージョニング (オンラインで見たものから) を使用しているようです。

1. これはアセンブリ バージョンのアイデアを置き換えるものですか、それとも追加するものですか? それとも、Nuget に慣れるだけですか。
2. 実行時にバージョンにアクセスする方法。Microsoft.Framework.Runtime パッケージで Nuget.SemanticVersion オブジェクトをオンラインで見つけましたが、コードでそれを取得する方法がわかりません。
3. ビルドまたはカスタム スクリプトだけでこの値をプログラムで更新する方法はありますか?