Pinned versions of dependent packages for the next major release #1148
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This prevents future minor/patch releases from unintendedly requiring higher versions of dependent packages, caused by ongoing package updates in the JADNC solution. How NuGet package dependencies in .NET work: - Package references are transient, which means that projects inherit package references from their dependent projects. Therefore there's no need to repeat dependencies in child project files. For example, when project X references package P, and project Y depends on project X, then project Y implicitly references package P (except when P was referenced using PrivateAssets in X). - To use the latest version of a dependent package, it must be referenced explicitly. For example, when package A v1.0.3 references package B v1.0.0, while the latest version of package B is v1.0.2, package B must be referenced explicitly to use its latest version. The rationale here is as follows: - JsonApiDotNetCore* projects (our NuGets) require a pinned version of dependent packages. Currently, these are Microsoft.EntityFrameworkCore and Humanizer.Core. The rest are dev-only dependencies. - Example and test projects explicitly depend on the latest release of EF Core and Npgsql, so we're always building against the latest versions. This enables us to notice breaking changes in patch releases of dependent packages before we release a new version. - Because Microsoft.EntityFrameworkCore* packages are always published together, there's no need to explicitly reference its core package. For example, by referencing just Microsoft.EntityFrameworkCore.Sqlite v6.0.3, we can trust that it depends on Microsoft.EntityFrameworkCore v6.0.3 and nothing else, so there's no reason to explicitly reference Microsoft.EntityFrameworkCore as well. - Npgsql.EntityFrameworkCore.PostgreSQL is maintained by another team, and there's usually a small window of divergence. Therefore we do reference both Microsoft.EntityFrameworkCore* and Npgsql.EntityFrameworkCore.PostgreSQL explicitly.
Codecov Report
@@ Coverage Diff @@
## master #1148 +/- ##
=======================================
Coverage 92.58% 92.58%
=======================================
Files 241 241
Lines 7700 7700
=======================================
Hits 7129 7129
Misses 571 571 Continue to review full report at Codecov.
|
maurei
approved these changes
Apr 6, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This prevents future minor/patch releases from unintendedly requiring higher versions of dependent packages, caused by ongoing package updates in the JADNC solution.
How NuGet package dependencies in .NET work:
The rationale here is as follows:
QUALITY CHECKLIST