@brianlagunas wrote:
Your UI framework is chosen when you open VS and say File -> New. You do need to choose your preferred DI container though. (Unity, SturctureMap, Ninject, etc). This is why we want one single container package. So if you wanted to use Unity as your container, you would just add Prism.Unity and no matter what UI platform you are writing for, you get the correct version. What we don't want to do is have a separate package for each platform for each container just for versioning (Prism.Unity.WPf, Prism.Unity.UWP, Prism.Unity.Forms, etc). Now image the same thing for the other five supported containers. Ouch!
Yes, it is realistic for a breaking change to happen in Forms and not WPF. These assemblies are specific to the platform, so some changes will never happen in one platform that may happen in another.
So it seems that reving them all to be the same is probably the best solution in this situation. Even in the case of breaking changes in one assembly and not in the other. We will just have to be clear in our release notes.
It also doesn't help that NuGet don't show the assemblies being referenced. Instead it just shows a package in the project References. Now there is no easy way to see what version the assemblies are in the referenced NuGet package.