Discussion: Don't add "ProjectReunion" to the Microsoft.WinUI package name
See original GitHub issueIn a recent screenshot, it showed that the WinUI package is changing from Microsoft.WinUI
to Microsoft.ProjectReunion.WinUI
.
https://twitter.com/marbtweeting/status/1367604242748346368/photo/1
I find this naming rather confusing to be in the product name.
Scott Hunter last week during the dotnetconf said “Project Reunion is a code word - it’ll change before we actually ship it”. So it seems to me you’re putting a temporary project name into the nuget, and I don’t really get the value add here either. If anything it just adds a some confusion. In the end it’s just a Windows app - how we get there is irrelevant to what you ship. Or to quote the reunion talk from Ignite 2021:
…eventually, the goal there is instead of thinking about desktop apps or UWP apps, we’ll bring those worlds together and we’ll just be thinking about Windows apps and libraries…
Another issue here is once Project Reunion is complete, you’re actually stuck with it. You can’t change the name of the nuget, or you’ll hose 3rd party libraries that takes a dependency on the nuget, and anyone using those 3rd party libs can’t grab a newer version of WinUI without waiting for the 3rd party vendors to re-release. And anything released on Preview 4 is definitely breaking (but since it was preview I guess that can be argued is OK but it’s just an example of how it already breaks anything already released)
Issue Analytics
- State:
- Created 3 years ago
- Reactions:28
- Comments:25 (18 by maintainers)
Top GitHub Comments
As I’ve heard Kevin Gallo say several times: “Projects are temporary experiments and may not turn into shipping products. Projects are not guaranteed to exist in the future or have ongoing support. Products are and do.” {paraphrase} By tying WinUI3 to the ProjectReunion name there is an underlying implication that WinUI3 might not stick around. For something that’s supposed to be the future of Windows development this is disturbing and does not build confidence that WinUI3 is a technology to be relied upon in the future.
If it’s mainly a matter of exposing all the Windows SDKs regardless of UWP or Win32, Microsoft.Windows.* makes sense. It’s “just windows”, but I think most of these can also stand on their own like
Microsoft.WinUI
, or forDWriteCore
instead ofMicrosoft.ProjectReunion.DWrite
, it would beMicrosoft.DWriteCore
etc.