You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pinned versions of dependent packages for the next major release
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.
0 commit comments