Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/dotnet/reactive/issues/205 below:

Implement assembly version strategy · Issue #205 · dotnet/reactive · GitHub

After a long discussion with @ericstj about #97, it seems like there's no really good options here, just one possibly "least bad" one.

To summarize the issue, when a package provides multiple assemblies that work on a platform the AssemblyVersion for each "higher/wider" version needs to be greater to ensure binding redirects work as expected. This means we cannot simply use the NuGet package version for all assemblies in the package. This is true whether it's net40 and net45 or netstandard1.0, netstandard1.1 and netstandard1.3 as we have today. The core issue is the same -- higher versions have a superset of the functionality as lower-platform versions.

In assembly versioning, it's generally considered the case that a higher assembly version contains all of the functionality of a lower one. This leads to the following "least bad" option:

• We will keep the major version of the assembly equal to the NuGet package (this is the one area we may have to reconsider)
• For each assembly in a compatibility level, we'll use a range within the assembly version. This gives us room for 1000 releases before we need to bump anything. Platform specific versions would use the range that matches its .NET Platform Standard version:
  • netstandard1.0: 3.0.0-3.0.999
  • netstandard1.1: 3.0.1000-3.0.1999
  • netstandard1.3: 3.0.3000-3.0.3999
  • net45: 3.0.0-3.0.999
  • net46: 3.0.3000-3.0.3999
  • win8: 3.0.1000-3.0.1999
  • wp8: 3.0.0-3.0.999
  • win81: 3.0.2000-3.0.2999
  • wpa81: 3.0.2000-3.0.2999
  • uap10.0: 3.0.4000-3.0.4999
  • netcoreapp1.0: 3.0.6000-3.0.6999

Given this model, we would increment Minor and Patch versions on the NuGet package as appropriate for the release, but each release would increment a value in the given range for the assembly. This will ensure that something isn't accidentally redirected to a higher assembly version with fewer/missing API surface area.

One open question is Major versions. Given that major versions are generally considered able to have breaking changes, it may be fair to bump the major assembly version to match. This could potentially lead to an issue if a 3.0.3000 assembly gets redirected to a 4.0.0 version that has less surface area. For a major release, this might be acceptable.

Thoughts?

/cc @bartdesmet @paulcbetts @mattpodwysocki @shiftkey @LeeCampbell @shana @forki @OmerRaviv @natemcmaster

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4