Enhance MSIX to support Semantic Versioning per http://semver.org #148
Description
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?