Enhance MSIX to support Semantic Versioning per http://semver.org

[DrusTheAxe]

Proposal: MSIX support for Semantic Versioning per http://semver.org

Summary

MSIX package identity supports versioning via major.minor.build.revision. This differs from Semantic Versioning in several ways, in syntax and function. It would be helpful to extend MSIX to support semver's syntax and semantics, both to expand MSIX' functionality and to reduce the impedance mismatch with software using semver.

Rationale

Semantic Versioning is increasingly popular for software projects. MSIX constrains how semver can be used with packaged software, sometimes severely (especially when bringing non-packaged software using semver to MSIX).

Scope

Capability	Priority
Major version changes have semantic meaning (breaking change)	Should
Version fields (especially major.minor.build) support for values >65535	Should
Support 'prerelease' syntax and semantics	Should
Support 'buildinfo' metadata	Could
Support existing MSIX packages and tooling	Must

Important Notes

MSIX package identity has a version of major.minor.build.revision SemVer has a version of major.minor.revision[-prerelease][+build]

These differ in syntactical and semantic ways.

Major version

Major in semver is a number and it has functional meaning e.g. major=3 is a breaking change vs major=2. It's significant.

Major in MSIX is just a number. You accomplish the functional meaning by putting the major value in your package name, e.g. KittyVideos version 4.5.6 in semver can be expressed in MSIX as package name = "KittyVideos4" and version = 4.5.6.0. That makes for a different package family from KittyVideos3 and KittyVideos5. That's how framework packages have done it to date e.g. package full name Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe broken down into the 5-tuple:

• name = Microsoft.NET.Native.Runtime.2.2
• version = 2.2.28604.0
• architecture = x64
• resource id = (empty)
• publisher id = 8wekyb3d8bbwe This gives consumers fine-grained control over taking a breaking change.

However, MSIX doesn't currently provide a way to say "Version >=1.2.3.4 thru 3.* are all equally good to me" as you'd need to say <PackageDependency ((Name="KittyVideos1" MinVersion="1.2.3.4") OR (Name="KittyVideos2" MinVersion="0.0.0.0") OR (Name="KittyVideos3" MinVersion="0.0.0.0"))> (or something equivalent).

Minor.Build.Revision vs Minor.Revision

These can be used equivalently if you set revision=0 in MSIX e.g. MSIX 1.2.3.0 and semver 1.2.3 are equivalent.

There is no impedance mismatch with semver if MSIX' Revision is not used (set to 0 and effectively ignored).

NOTE: Store requires MSIX packages be submitted with Revision=0.

MSIX Version Values are 0-65535

MSIX version values (major, minor, build, revision) only support values 0-65535. When MSIX was created in Win8 the common "DotQuadNumber" versioning scheme was adopted, i.e.

struct DotQuadNumber
{
    UINT64 major, minor, build, revision;
}

Also sometimes expressed as UINT16[4], thus each element supports values of 0-65535

MSIX's definition prevents common versioning strategies e.g. minor=date as YYMMDD, or YYMMDDHHMM.

Semver values aren't limited to 65535. Semver's definition is unbounded ("0" or 1-9 followed by any number of characters 0-9) but at least raising MSIX' limits UINT32 would help meet the majority of versioning strategies used by various software projects.

SemVer prerelease

MSIX has no exact match to semver's prerelease. MSIX's revision field is similar, but the sort order rules differ e.g. given a release and a prerelease MSIX sorted order would be [1.2.3.0, 1.2.3.1] whereas semver would be [1.2.3-1, 1.2.3]

SemVer buildinfo

semver's buildinfo is informative metadata. MSIX package identity has no equivalent concept. You can add this sort of data into appxmanifest.xml e.g.

<Package>
...
    <BuildInfo>
        <Foo>bar</>
        ...
    </>
</>

but as that's not in a known namespace it's effectively invisible when Windows processes the package. You'd need to lookup the package's install location, load its appxmanifest.xml and parse out the metadata.

Would it be acceptable to add something like this to appxmanifest.xml with APIs to make accessible instead of supporting a -buildinfo suffix on a version string?

Open Questions

MSIX includes version in package identity which is a foundational and pervasive construct across Windows, tooling and applications across the ecosystem. Any change to package identity poses compatibility challenges. Can MSIX version be changed without unacceptable compatibility issues?

[DefaultRyan]

Very informative to see that framework package authors have adopted the "MyWidget4" major versioning approach.

I'm working on plans to help component authors support loading multiple versions side-by-side in a single process, and that versioning approach actually sounds like it will help somewhat. See #153

[Jayasankar-m]

Any update on this ? Support for semver versioning is very critical .. When there are frequent prereleases its difficult to maintain versions. Hope it will be addressed soon..

Thanks