@csharpfritz wrote:
You've really got a confusing block of packages and support verticals there before we even look at the version numbers. Am I understanding correctly that I need to choose a DI platform and a UI framework before I can decide which Prism top-level package to install? While that delivers a nice collection of thin packages with a cool dependency resolution graph, is that something that your average or below average developer is going to be able to navigate from a NuGet search?
I don't think there is always a direct correlation between package version and library version. In the case of the "fat package" that you are describing that contains multiple DLLs, it would be preferred if they were all in sync with the version number of the package. However, I don't think that's realistic in all situations. This leads to a semver discussion: if you are updating Prism.Unity.Windows.dll to v2 - what breaking API change did you make? You should flag that to your package consumers that a breaking API change was made to one of the component libraries, driving the package version to 4.0.0 ...and now things are skewing even further.
Is it realistic to make a breaking API change in Windows and NOT in Forms or WPF? Perhaps, but that is for you to manage.
In the case of ASP.NET, we are aligning all DLLs and packages versions on every release. That way there is no confusion, even if there are no changes, they are all pushed to the same version number with proper dependency constraints defined in the NuGet package to ensure that appropriate dependent packages are installed with the new package release.
