Windows Terminal Versioning is too awkward

[rgl]

Windows Terminal version

No response

Windows build number

No response

Other Software

No response

Steps to reproduce

The Windows Terminal Versioning is too awkward and should be normalized into a single version.

Having a different version per OS is too awkward, and it makes its usage too awkward.

This is quite noticeable in this repository. The release is at https://github.com/microsoft/terminal/releases/tag/v1.16.10261.0 BUT when you actually try to download the binary for windows 11, its actually 1.16.10262.0, which completely brakes any reasonable expectation of what a release tag is.

This also makes the release title quite awkward, there are three versions in there: Windows Terminal v1.16.1026 (1.16.10261.0 and 1.16.10262.0).

Expected Behavior

The same version released for all the OSes.

Actual Behavior

1.16.10261.0 for windows 10

1.16.10262.0 for windows 11

[zadjii-msft]

Thanks for the feedback! We agree - thing is wholly not ideal. This thread: #14106 has a lot more details on why it's so awkward, specifically this comment: #14106 (comment).

Starting in 1.17, we're trimming off the last digit of the rev in both the Release tags and the About Dialog, to try and make it clear that both 1.XY.ABC1.0 and 1.XY.ABC2.0 are really the same version.

[rgl]

Thank you for pointing me to that thread.

If I understood correctly, starting with https://github.com/microsoft/terminal/releases/tag/v1.17.1023 the 5th digit is no longer part of the tag nor the UI, but still present in the actual package filename and store listing?

Instead of changing the version, why not change the actual package name to include the OS and use a non-tweaked version in that package (e.g. Microsoft.WindowsTerminalWindows10 version 1.17.1023)?

[DHowett]

Unfortunately, we cannot change the package's name because that would assign it a totally new identity; they could be installed side-by-side, users upgrading from Windows 10 to Windows 11 would naturally end up with two, and they would not share settings.

This isn't a great situation, but until such time as we can ship the same package to Windows 10 and Windows 11 (which should be soon?) it's unfortunately going to have to stand. I'm sorry.

[rgl]

Understood. Its a loose-loose situation. Is this because of the Windows Store limitation that you've mentioned in #14106 (comment)? which are being fixed in the near future, and that's what you mean by which should be soon??

[DHowett]

Ah, the limitation is a platform bug. When you run a store package as admin on Windows 10, it may not be able to find its dependency packages (that is: Terminal wouldn't be able to find the VC++ Runtime or XAML packages!)

We believe it's been fixed and that the fix has been released broadly, but I need to track down the official version numbers before I release an update that might not work for Windows 10 users who have not updated.

[rgl]

Having that in 1.17 would be super :-)