-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lock the major version of all dependencies in the NuGet packages #1236
Comments
I think that would help a little. At least we would let minor package updates occur. Any major updates would be a risk of breaking binary compatibility. |
not so sure that this will be necessary. Obviously the change in ownership in CSL and Unity has resulted in major breaking changes that I just don't see as a common occurrence. We could also be introducing problems for people consuming other packages. Lastly, with the new templates and anyone who migrates to the newer project structure they won't see dependencies listed in the NuGet Manager like the older project style. |
Dan makes a great point. The new projects will not suffer form the "upgrade everything" issue that NuGet has. |
I think I am going to close this for now as I don't see this as an immediate need. If we continue to have issues, we can bring it up again. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Following #1175 and #1211, we should consider locking the major version of our dependencies. Minor versions shouldn't be an issue if our dependencies follow SemVer (bump major on breaking change).
Upside: this disables the user of Prism to upgrade to a breaking change of a dependency (e.g. CSL 2.0 for Prism 6.3). This will prevent possible bugs that arise out of untested code or even the inability to compile because of changing API surface of the dependency.
Downside: this disables the user of Prism to upgrade to a new major version of the package that most likely doesn't have impact (e.g. Json.net comes to mind to having bumped several major versions without breaking changes). We would have to publish a new package to support a non-breaking major package bump on the dependeny.
The final question is: do we lock all our dependencies or the most critical ones only (e.g. IoC containers).
NuGet reference for version locking: https://docs.microsoft.com/en-us/nuget/reference/package-versioning#version-ranges-and-wildcards
The text was updated successfully, but these errors were encountered: