Open DrusTheAxe opened 4 years ago
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
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
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
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:
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.
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.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?