Naming, Versioning and Releasing Project Reunion and Windows UI

As the first release of Windows UI 3.0 is imminent, there’s a bit of a dialogue going on about its relationship with the parent project, Project Reunion. More specifically the conversations focus on topics like naming, versioning and release planning. In this post I’m going to touch on these topics and provide my thoughts on some things that should increase transparency and communication between Microsoft and the now-frustrated and confused Windows developer community.

Naming

The first challenge when it comes to naming is that Windows UI (aka WinUI) has be recycled. There is a general understanding under SemVer that when you step between major versions (eg 2.x to 3.0) there will be some breaking changes. In the case of WinUI, there is no way to simply upgrade from WinUI 2.x (which is used within a UWP project) to WinUI3 (which currently, and perhaps indefinitely, is not supported in a UWP project). The only reason that the WinUI name make sense is that v3.0 will essentially be a superset of WinUI2.x.

The second issue when it comes to naming is Project Reunion. From the onset, Project Reunion has a great marketing angle – it pretty much described exactly what Microsoft was intending to do with the project. For too long there was all these disparate frameworks for building for Windows. Project Reunion was about unifying these frameworks under a common umbrella….or at least giving them a common set of components that they could leverage.

Unfortunately, Project Reunion is not a great name for a product or framework or whatever you want to call the actual output of this project. There should never be any packages that are names “XXXX.ProjectReunion.XXXX” as this doesn’t mean anything in the context of a project. For the most part the ProjectReunion part should just be dropped and/or replaced with something more meaningful.

Packaging and Dependencies

Let’s continue the discussion on packaging as this seems to be a topic that has some developers hot under the hood. For a long time WinUI has been a standalone package that developers could add to their UWP project. With WinUI 3.0 it was a little harder to simply add a reference and you were better off starting a new project based on the templates that were shipped via the Visual Studio Extension.

As we approach the general availability of WinUI3.0, there’s been a shift to include WinUI as a sub-component of Project Reunion. As such, when you create a new project, you’re now creating a project with a reference to the Microsoft.ProjectReunion package. This in turn brings in references to the Microsoft.ProjectReunion.WinUI package which is WinUI.

The thinking for this approach is that Project Reunion is the umbrella package for all the new features that Microsoft will be rolling out. Rather than developers having to pull in different packages and navigate dependencies etc, they just have to pull in the ProjectReunion package and it will provide them with all the necessary components to build Windows apps of the future. As Microsoft adds features, increments versions etc, developers just need to upgrade a single package in order to get the benefits.

Personally I think this approach is great – it’s super simple and shouldn’t matter if you a WinForms, a WPF or a WinUI developer, you simply need to have a reference to ProjectReunion (and yes, I’ve left off UWP developer as I think their path forward is to convert to a WinUI desktop app).

The downside to this approach is that there is a high risk that some parts of ProjectReunion may interfere with the way existing applications run. For example there’s currently a bug where ProjectReunion (well actually the WinUI package) interferes with the XAML parsing which prevents compilation of a WPF application if they add the ProjectReunion package. As such, it would be preferable if the individual components of ProjectReunion could be referenced independently. I understand that this may not be possible as there may be dependencies between some of the ProjectReunion packages but this should be one of the goals.

I’ll go into versioning in a bit more detail in the next section but I wanted to point out that it’s important that individual components within ProjectReunion can be versioned independently. Whilst ProjectReunion may have say a 6 month versioning cycle, there’s no reason that the individual components can’t push out incremental versions out of band. Having every component align with a single versioned package is fundamentally a bad idea and will simply act as a roadblock for the different teams shipping features.

Versioning

When WinUI was rolled into Project Reunion it added a bit of confusion around how things were to be versioned. On one hand we’re looking at version 3.0 of the WinUI library but this is part of the 0.5 release of Project Reunion. This was compounded by the renaming of the WinUI library to include ProjectReunion in the naming.

If you think of Project Reunion as an umbrella package that simply pulls in various components that a Windows developer would want access to, the versioning makes sense. Each of the components can have their own version (see previous section for my comments on components versioning independently). The version of the Project Reunion package essentially becomes a simple way for developers to pull together a specific set of components – developers who don’t need/want to reference specific versions of the individual components can simply upgrade the Project Reunion package.

One of the things I would like to see added to the discussion around Project Reunion is the generation of a Long Term Support (LTS) release. Each of the components of Project Reunion should be considering which release they make an LTS and then Project Reunion should provide a LTS release that is made up of only LTS component packages.

Release Process / DevOps

One of the topics currently open for discussion on the Project Reunion repo is around the use of channels for releasing new features. However, I think there is a wider conversation to be had around devops for Project Reunion. I think this also applies to each of the components of Project Reunion but rather than try to form one mega-project, each component should be running independently but have a shared roadmap for feature releases (and yes, this should also align with other teams such as the roadmap for .NET).

Source Control / Open Source

The first, and arguably most important, piece is to get all the source code into an open source code repository. I don’t understand the resistance here, other than a general reluctance to a air the dirty laundry that we all know goes into shipping products in the real world. Once the source code is published, there’s no going back and the team becomes 100% accountable to the community.

But, getting the source code into the open isn’t enough, the whole project needs to move to an open source mindset where all the discussions, planning and management is done in the open. This should not be done using the tools offered by GitHub (which are just plain awful for managing actual software development projects). Instead, Microsoft should use their own Azure DevOps to manage code, define roadmaps, plan sprints etc. There’s no reason why the whole thing can’t be managed as a public project within Azure DevOps.

Build/Release Pipelines

Following on from the previous point, in addition to the source code being in the public, the build and release pipelines should also be in the open. Again, picking the right tool for the job (i.e. Azure DevOps, not it’s infant half-brother, GitHub Actions) means that the entire pipeline can be made public, without Microsoft exposing any internal certificates, passwords and other proprietary resources.

Furthermore it’s about time that Microsoft adopts the tooling that they expect their customers to use – if they can’t ship Project Reunion using the tools, then how do they expect customers to ship their products!

Release Channels

The last topic that I want to comment on in this post is the discussion about using channels to give developers early access to new features/fixes that are being rolled out. I applaud the openness on this topic but I think it’s been had in isolation to the way that the source code is going to be managed. If you look at the way other large open source projects (eg Flutter channels) are managed and the way they manage channels, it’s evident that there is a strong correlation between the way their source code workflow operates and their release process to the different channels.

I would encourage Microsoft to look at the entire workflow from commit through to release and work out what this mapping looks like. Publish this as a discussion and let’s make sure that the entire process is going to work for both Microsoft and the community.

Summary

There’s quite a bit to digest here but the upshot is two key points

• Project Reunion should be an umbrella project that brings together a number of components that are useful for Windows developers. Components should be independently versioned, freeing up the teams to iterate at their own velocity
• Project Reunion, and all components, should move to be open source both in terms of source code and the way the projects are managed. This will further transparency, build engagement with community and instill more confidence in the Windows developer community.