OASIS SDD TC Version Proposal

1
OASIS SDD TC Version Proposal

• Brent A. Miller
• STSM, IBM Corp.

2
Current State

• schemaVersion ltmajor.minorgt
• We control this
• This is done þ
• versionStringType ltV.R.M.Lgt
• We specify this
• This is incorporated in the specification
• Used in (PD).packageIdentity.IdentityType,
  (DD).resultingResource.backwardCompatibility,
  (DD).resource, (DD).resultingResource,
  (DD).rootxU.identity, (DD).ResourceConstraintGro
  up.versionConstraint
• We specify a version comparison algorithm

3
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

4
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 computers version identification information
  is Version 5.1 (Build 2600.xpsp_sp2_gdr.050301-15
  19Service Pack 2)
• Windows version numbers (5.1) are little used
• XP serves as a major version number, but
  doesnt 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

5
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
• Doesnt improve the situation, weakens rigor of
  SDD
• Regardless, SDD must provide version comparison
  guidance

6
Proposal

• Accommodate (import) all version specifications
• genericVersionString
• Specify mapping to VRML in profiles
• Manufacturer-to-SDD neutral vocabulary
• a la packageType (etc.)
• Add fix information
• Maintenance level, patches
• Consistent with fixInformation
• Result is
• Normalization of version information
• Best (VRML) version specification, enhanced
  with fix information

7
Example (1)

• Windows Version 5.1 (Build 2600.xpsp_sp2_gdr.0503
  01-1519Service Pack 2)
• Accommodate (import) all version specifications
• genericVersionString Version 5.1 (Build
  2600.xpsp_sp2_gdr.050301-1519Service Pack 2)
• Specify mapping to VRML in profiles
• V5
• R1
• MBuild 2600.xpsp_sp2_gdr.050301-1519Service
  Pack 2
• LØ
• Add fix information
• Maintenance LevelService Pack 2
• PatchesMS04-014 (837001), MS04-032 (840987),

Ø
8
Example (2)

• RHEL RHEL AS 3 Update 8 k2.6.10-xenU
• Accommodate (import) all version specifications
• genericVersionString RHEL AS 3 Update 8
  k2.6.10-xenU
• Specify mapping to VRML in profiles
• V3
• RAS 3
• Mk2.6.10-xenU kernel version
• LØ
• Add fix information
• Maintenance LevelUpdate 8
• PatchesSecurity Errata,

Ø