Project Reunion and the path to an official product!

[tfennel]

As many of you have noticed, earlier this month we released a preview of WinUI 3 underneath the "Project Reunion" 0.5 preview package. And today we released the Project Reunion 0.5 release. You might be wondering, "project" sounds a bit temporary. Can I trust this? Can I build my apps on this?

Project Reunion is a temporary name

Everybody's got to start somewhere right? 😉 The name "Project Reunion" is NOT our final name. We're still working on that. ⚒
Through our 0.5 and 0.8 release we'll retain that name. If you have opinions/ideas for the final name we welcome hearing them!

We will definitely end up renaming some of our artifacts (Nuget package, etc) again closer to the 1.0 release.
We realize that not having the name finalized will have an impact on your developer workflow. Specifically, the WinUI 3 NuGet package used to be how you consumed WinUI 3, but now you'll consume it through Project Reunion. As a result, the package you used to reference needs to be updated to the Project Reunion NuGet. Namespaces are all planned to remain the same, though there are a few that didn’t make it in the preview, but those are bugs that we’re fixing. So if you’re a WinUI customer then your WinUI code and references should remain durable throughout. The goal is that you explicitly move to the newer versions as we release them later this year so there’s no surprises for your apps at runtime.

Project Reunion is a fully supported effort

0.5 is a fully supported release. For some people, having “Project” in the name means it might not be supported, but that’s not the case here. We're fully moving our Windows developer platform efforts into "Project Reunion". You can bet on it as the open source, decoupled SDK strategy for the Windows developer platform long term. This is where we're putting our effort and where we hope you'll put yours too! 💪

The 0.x release cycle means things will change

In our minds, the 0.x release cycle is meant to be an indicator that things can/will change. Since you need to upgrade your app to a get a newer version of the SDK, you will be able to control the impact it will have on your app.

Some specific examples of those changes:
• The name of the Project Reunion metapackage, and it’s version, will change for 1.0
• The name of the WinUI 3 subpackage, and it’s version name, will change for 1.0
• APIs will change in WinUI 3

Breaking changes may happen

We'll do our best to minimize them, but between 0.5, 0.8 and 1.0 there will undoubtedly be some. 💥 We'll communicate them ahead of time as best as possible. Suggestions on how folks like those kind of things communicated or models you've seen work best in the past are welcome!

Here's an example of what some aspects of something like a naming change might look like for both developers and folks using/building 3rd party Project Reunion libraries:

For devs directly using Reunion (not using any 3rd party Project Reunion libraries/etc):

• In 0.5, namespaces of DWriteCore/MRT Core might be Microsoft.Resources/etc (only impacts DWriteCore/MRT Core)
• In likely 1.0, those namespaces will move to Microsoft.FinalName.Resources/etc (thus a breaking change, devs will have to update their namespaces)
• WinUI is going to stay in Microsoft.UI, so no breaking change there
• Additionally, to “update” to the 1.0 version of Reunion, you will have to…
  • Uninstall Reunion NuGet from their project
  • Install “FinalName” NuGet to their package

For devs building 3rd party Project Reunion libraries:

• Call to action: Update your libraries as quickly as possible so devs can use them ⌚
• Switch from the Reunion NuGet to the “FinalName” NuGet

For devs using 3rd party Project Reunion libraries:

• Make sure your favorite 3rd party Project Reunion library is updated
• Update your 3rd party Project Reunion library's NuGet version like normal 👍
  • 3rd party Project Reunion library under the scenes switched from the Reunion NuGet to the “FinalName” NuGet, devs don’t see this
• If 3rd party Project Reunion library exposed any types from DWriteCore/MRT Core, devs would hit breaking namespace changes (could happen, but seems unlikely)
• If devs happen to also use Reunion directly themselves, they have to do the above same as devs directly using Reunion

Now what?

More than anything we want your feedback. For example there's been great questions lately around our versioning strategy and release cadence we're working through in the discussion with you, but we know there's more and we look forward to answering your questions!