Bump WinGet version to align with App Installer
Closed this issue · 6 comments
Relevant area(s)
WinGet CLI
Description of the new feature / enhancement
After WinGet 1.12 ships, we should bump the "minor" version to align with the App Installer. Lots of folks have been confused about which version of WinGet/App Installer they have.
This hopefully will alleviate some of that confusion.
Proposed technical implementation details
No response
I would love it if we could find a version to jump to that feels more meaningful than 1.28, or a cooler reason than just aligning the two...
We also haven't shipped 1.12, so in theory we could still change the number in this release. The WinAppSDK update sounds like a good excuse in this one
Lots of folks have been confused
I dunno...I don't think this will help alleviate the confusion rather make it worse for the average WinGet user. I can imagine the new questions being:
Q: Why did WinGet skip so many versions?
A: To match the App Installer version
Q: Okay...but what is App installer?
A: WinGet is distributed as part of the App Installer framework that contains other components as well.
Q: Okay.. but why does it matter for the average WinGet user?
A: ...<insert reason here>
I feel like an average WinGet user, myself included, doesn't bother with what App Installer is and its version. If someone REALLY wants to know, I would just redirect them to look at the output of winget --info. If the team does decide to go down this route however, I think there are some other questions that need clarification
-
Can the App Installer minor version be bumped by an update to any other component in the framework other than WinGet? If so, does that mean that this wouldn't be the ONLY time you jump versions but may have to do it occasionally?
-
Would WinGet match only the minor version or the entire version string including build/patch would be identical? If it's only minor version, I feel the person who wants to know which App Installer version they have would still need to go to
winget --info, which I feel slightly defeats the purpose of reducing the overall confusion
Personally, I would let it be the same way it is right now and retain the semantic meaning of a version bump for users unaware of App Installer. A user may see an upgrade from WinGet 1.12 -> WinGet 1.28 as a giant upgrade when it's really just the next increment. I also don't think it is uncommon for sub-components of a package to follow a different versioning scheme than the parent package, but could be wrong here. In my head, this kind of change may be best suited with a WinGet 2.0 release
(yes I know this technically isn't a breaking change, but 2.0 may be a good time to introduce these confusions when folks would already be learning about new stuff to migrate towards :D)
Can the App Installer minor version be bumped by an update to any other component in the framework other than WinGet? If so, does that mean that this wouldn't be the ONLY time you jump versions but may have to do it occasionally?
The only two components in the package are App Installer and WinGet. They have different minor version because App Installer started ahead: we published winget 1.0 with App Installer 1.15. Since then, the number has been increasing in parallel for both. The bump would be a one-time thing to align them.
Would WinGet match only the minor version or the entire version string including build/patch would be identical?
The build and patch versions already match between App Installer and winget, including the NuGet packages and PowerShell modules. (Note that the patch version is always 0 due to requirements from the Store, and the build version for the package is 1 smaller than for winget if configuration is disabled.)
The only two components in the package are App Installer and WinGet
I see...doesn't sound too bad then. Thank you for the information. I still feel users will be surprised by this change, although if this is documented well in the release notes then I'll be happy :D
I would love it if we could find a version to jump to that feels more meaningful than 1.28, or a cooler reason than just aligning the two...
We could say "28" stands for 2028, just like another OS...