FpML Versioning An AWG Discusion Document

Versioning in FpML To Date Based on major.minor numbering –Major increments to indicate a breaking change –Minor increments with each non-breaking change Numbering rules have not be rigorously implemented –4.1 EQD model incompatible with 4.0 –4.3 CD model technically incompatible with 4.2

Technical vs. Marketing Numbering Standards committee prefers to minimise major number changes –Makes it seem that difference between all releases are minor –Must read the release notes to discover the details of the changes Goes against FpML rules of operation

Why Change? To implement document backwards compatibility –Compatible schemas must share a common namespace Most FpML releases are structurally backwards compatible BUT documents must be altered before processing –Change would eliminate need for document alterations –Can reduce the maintain required to update implementations

Build Numbers Can be considered as an additional part of the version number –e.g. Major.Minor.Build Useful to implementers using working drafts No changes to build numbers are considered

Options

Option 1: Continue Ad-hoc Numbering Continue with current system for 5 and later Pros: –More control over version numbering Cons: –Not possible to implement backwards compatibility –Versions give no indication of technical difference since last release

Option 2: Rigorous Two Part Numbering Implement version rigorously to FpML operating rules –Current FpML 4.3 should be 6.1! Pros: –Version numbers reflect technical difference and ease of implementation –Allows backwards compatibility through namespace URI containing only major number Cons: –Major version numbers would increment more frequently

Option 3: Two Versions Each schema given two identifiers –A marketing name used in publications e.g. FpML 5-A –A technical major.minor number in the schema Pros: –Marketing identifier changes less frequently than technical version Cons: –Not easy to determine compatibility from marketing name –Not easy to map between marketing and technical numbering –Namespace based on marketing name would not support backwards compatibility

Option 4: Three Part Version Number Version number becomes –Architecture.Major.Minor (e.g 5.0.0, 5.0.1, 5.1.0) Schema namespace URI predictably derived from version number –Architecture.Major (e.g. 5.0, 5.1) Pros: –Leading digit remains consistent across many releases –Supports document backwards compatibility Cons: –Architecture number out of synchronisation with documentation Come up with a better name? –Changes version attribute –Version is not a number may affect some implementations

Observations Implementers need to see how similar or different releases are –Current scheme disguises the amount of change Backwards compatibility can only be done if version numbers are technically defined –Breaking changes MUST change the URI

Other Thoughts Should we have a standard root element attribute that defines schema status? –status=wd or tr or rec

Recommendation What?