OASIS SDD TC Version Proposal Brent A. Miller STSM, IBM Corp.

Current State schemaVersion: –We control this –This is done  versionStringType: –We specify this –This is incorporated in the specification –Used in (PD).packageIdentity.IdentityType, (DD).resultingResource.backwardCompatibility, ( DD).resource, (DD).resultingResource, (DD).root[x]U.identity, (DD).ResourceConstraintGroup.versionConstraint –We specify a version comparison algorithm

Problem Statement (1) We control the “make it up” version specifications –schemaVersion –Descriptor identities We do not control the “look it up” version specifications –Resource –resultingResource –Version constraints Hence, we cannot constrain version to VRML format in all cases

Problem Statement (2) In just one hosting environment (OS), in just several popular OSes, we find “version” information consisting of some combination of: –Generation –Edition –Ver –KernelVer –Maint –BuildNum –CodeName –ProdNum My computer’s version identification information is “Version 5.1 (Build 2600.xpsp_sp2_gdr :Service Pack 2) ” –Windows version numbers ( “5.1” ) are little used –“XP” serves as a major version number, but doesn’t appear as a classic one –Build number is a key identifier, but does not update the version number –Etc. (and similarly in other OSes/hosting environments/applications…) Fixes (maintenance level, patches applies) are key version indicators in many OSes

Alternatives Specify superset of known version identification mechanisms –Generation –Edition –Ver –KernelVer –Maint –BuildNum –CodeName –ProdNum  Will this cover all hosting environments? Map everything to VRML [’]  Is this possible? Specify subsets per hosting environment (profile)  Will this cover the full spectrum? Enrich current structured version information (VMRL++)  How many version specifiers? Is this possible? Allow free-form version specification and (partially) punt  Doesn’t improve the situation, weakens rigor of SDD  Regardless, SDD must provide version comparison guidance

Proposal 1.Accommodate (“import”) all version specifications genericVersionString 2.Specify mapping to VRML in profiles –Manufacturer-to-SDD neutral vocabulary –a la packageType (etc.) 3.Add “fix” information Maintenance level, patches Consistent with fixInformation  Result is:  Normalization of version information  “Best” (VRML) version specification, enhanced with fix information

Example (1) Windows “Version 5.1 (Build 2600.xpsp_sp2_gdr :Service Pack 2)” 1.Accommodate (“import”) all version specifications genericVersionString= “Version 5.1 (Build 2600.xpsp_sp2_gdr :Service Pack 2)” 2.Specify mapping to VRML in profiles –V=“5” –R=“1” –M=“Build 2600.xpsp_sp2_gdr :Service Pack 2” –L={Ø} 3.Add “fix” information Maintenance Level=“Service Pack 2” Patches={MS (837001), MS (840987), …} Ø

Example (2) RHEL “RHEL AS 3 Update 8 k xenU” 1.Accommodate (“import”) all version specifications genericVersionString= “RHEL AS 3 Update 8 k xenU” 2.Specify mapping to VRML in profiles –V=“3” –R=“AS 3” –M=“k xenU” [kernel version] –L={Ø} 3.Add “fix” information Maintenance Level=“Update 8” Patches={Security Errata, …} Ø