SemVer compatibility in AppXManifest

[LadderLogic]

The current package appxmanifest for windows sdk apps supports 4 digit version in the format of Major.Min.Patch.Build. The SemVer standard however is Major.Minor.Patch+Build. Using the SemVer standard for build number, as defined here https://semver.org/, in appxmanifest throws a build time schema validation error.

What is the correct repo/team that can answer the reasoning behind this, and if there is a workaround to be semver compatible?

[DrusTheAxe]

Most of the answers you seek can be found in #148

One item not mentioned there is MSIX predates SemVer. There was no SemVer when MSIX was invented, but there was plenty of existing DotQuadNumber (a.b.c.d) at the time.

Some parts of SemVer can be mapped to MSIX. MSIX uses a 4-part number (Major.Minor.Build.Revision) but if you always define Revision=0 you can use the same value as SemVer e.g. SemVer 1.3.5 == MSIX 1.3.5.0.

BTW your SemVer definition is incomplete. That should be Major.Minor.Patch[-prerelease][+buildmetadata].

SemVer's prerelease field is problematic in multiple ways (especially allowed values + sorting). See Issue #48 for more details.

SemVer's buildmetadata is less problematic but not entirely problem free. If you want metadata about the package you can add information to the MSIX package's appxmanifest.xml as in an ignorable namespace and MSIX will ignore it. Alternatively, if you add information in the manifest under an <Extension Category="windows.appExtension"> you can query that info via the AppExtension API. SemVer's buildmetadata doesn't map so well into MSIX's package identity so 2 packages identical except for buildmetadata doesn't express so well via MSIX.

Windows App SDK has a versioning model. How that's mapped to MSIX, Nuget, VSIX and other tech is a per-tech decision. They don't all support the same options and behavior so we decided how each should express WinAppSDK's versioning and identity to best fit our needs within the abilities and constraints of each tech. One size doesn't fit all. See MSIXPackages.md and MSIXPackageVersioning.md for details how and why WinAppSDK defines its MSIX packages' identity and versions.