Our policy since 1.0.0 has been to always cascade version updates in the packages we own. e.g. if Logging has a product change in 2.1.x, then Kestrel, EF Core, Mvc, etc also re-ship with the updated Logging dependency. This has been done for a variety of reasons:
* NuGet does not show updates for transitive dependencies, only direct ones
* NuGet does resolves the lowest compatible transitive dependencies
* ASP.NET Core ships to both .NET Framework (where transitive dependency version matters) and .NET Core (where it matters less if you use the shared framework)
While transitive dependencies is still an important scenario, this practice of always patching has led to bigger issues.
* High probability users will unintentionally upgrade out of the shared framework: #3307
* Conflicts with metapackages that attempt to use exact version constraints: aspnet/Universe#1180
* A quality perception issue: the high volume of new versions in servicing updates with only metadata changes has created the impression that new versions of packages may not be very important. It's also made it appear like there are more issues product than there really are.
* High volume of packages changing with only metadata changes. Of the last 301 packages published in a servicing update, only 11 contained actual changes to the implementation assemblies. (3.5%)
This change implements a system to verify a new, non-cascading versioning policy for servicing updates. This required changes to repos to pin version variables to that matter per-repo,
and to remove some of the restrictions and checks.
Incidentally, this should make defining new patches easier because it automatically determines which packages are or are not patching in the release.
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
Originally, we thought using exact version ranges on the dependencies of Microsoft.AspNetCore.App
would help protect consumers from lifting binaries out of the shared framework. However,
this makes it difficult for consumers to use packages that share a dependency with .App.
When users tried to mix Microsoft.EntityFramework.SQLite 2.1.1 with Microsoft.AspNetCore.App 2.1.0,
NuGet errors and warnings made it difficult to reason about what was wrong, and how to resolve it.
This changes the dependency version range to allow uses to upgrade within the major.minor patch family
without needing to override NuGet warnings. This removes some of the protections against users
unintentionally lifting to a binary newer than the shared framework, however, after lots of discussion,
we believe this is a better user experience.
- Upgrade build tools
- Produce an SVG badge for the sharedfx
- Produce the 'latest.aspnetcore.version' file for the dotnet-install.ps1/sh downloader script
- Change layout of output for sharefx build
- Use KoreBuild's bundled package folder for internal build tools packages
Nate McMaster
Nate McMaster
Justin Kotalik
John Luo
Pranav K
=