Repository navigation
Pre-release versioning doesn't make sense #6679
Description
Why are the pre-release tags incrementing outside of major/minor releases?
https://www.nuget.org/packages/Microsoft.WindowsAppSDK/#versions-body-tab
{{ message }}
Why are the pre-release tags incrementing outside of major/minor releases?
https://www.nuget.org/packages/Microsoft.WindowsAppSDK/#versions-body-tab
Activity
riverar commentedon Aug 11, 2026
Each major+minor release is its own isolated bubble. Pre-release and version state don't carry over from one release line to the next. A 2.0.0-experimental1 and a 2.1.4-experimental1 share no context. Each release should restart its prerelease numbering at 1.
You don't do this in Windows: Windows 25H1 Beta 1, Windows 25H2 Beta 2, Windows 26H1 Beta 3, Windows 26H2 Beta 4, ...
I expected to see:
christosk92 commentedon Aug 13, 2026
Welcome to Microsoft product managers. I mean just look at the graph api which is in beta and throws transient errors all over the place and the suggested fix is: just retry it again "lmao" .
Then look at Azure.
Then look at .... every other msft product ..... The inconsistency is just rooted in their PMs
agniuks commentedon Aug 25, 2026
Thanks for raising this. To make our experimental release versions clearer, we’ve simplified the versioning convention.
Starting with today’s 2.4.1-experimental release, experimental NuGet package versions will use
-experimentalwithout an additional numeric or alphanumeric revision suffix. We’ll follow this convention for future experimental releases as well. The MSIX version will retain an internal revision to prevent automatic updates between experimental releases, but that revision will not appear in the public NuGet package version.We welcome candid feedback and ask only that the discussion remain focused on the product and its decisions rather than the people behind them.
christosk92 commentedon Aug 25, 2026
Where is your responsibility ? You killed WinUI/WinAppSdk. Usage is nihil. It's just people making apps for each other
Agents are terrible at writing WinUI3 xaml, people are just building more and more web apps or native apps using SwiftUI for iOS/macOS, WPF for Windows.
The treshold to develop native apps is almost non existent anymore thanks to agentic coding, so why waste time on a poorly documented framework that gets updated poorly, is poorly versioned, lacks basic features, poor performance and barely any support.
I ask my agent to develop me a windows app in WPF, it will have no trouble doing it. Ask it to develop a WinUI app, and it looks like a 6 year old built it using scratch. It does not know the difference between WPF and WinUI3, sometimes writing illegal WinUI3 code, like multi bindings, always using {Binding} instead of {x:Bind} etc.
I think its more than fair to criticize the people behind it, since its the product managers who directly have influence over the product development, its marketing and usage, both internally at microsoft themselves, and externally by developers.
Developers, who by the way, have spent years hoping for change and improvement and were dissapointed at every step, starting with UWP
riverar commentedon Aug 25, 2026
I strongly urge you to revisit this strategy and work with the community to get this right, especially given the team has screwed this up multiple times now.
How do you propose the next 2.4.1 experimental release will be versioned? I hope you don't intend to change the major/minor/patch numbers...
Prior discussions:
RDMacLachlan commentedon Aug 25, 2026
Rafael Rivera (@riverar), with the shift to 2.x and semantic versioning, there is no re-use of major, minor, patch versions with releases.