8.Versioning & compatibility

An IPL version is written X.Y.Z. Each digit answers one question about what a release changed; the digits to its right reset to 0 when it increments.

• X — paradigm shift. The representation model changes, or existing P vectors stop being valid. This covers a replaced or re-partitioned vector (the group model of §3 changes, the [−1, 1] convention changes, or P stops being the canonical representation) and every breaking registry edit (§4): an axis removed, an id reused, or an axis's meaning or range redefined. A new X starts a new vector lineage: vectors, decoders and scripts of an earlier X are not expected to carry over without conversion, and the release MUST be recorded as breaking with a migration note.
• Y — major change. The document gains normative capability within the same paradigm while every existing vector stays valid: one or more axes added to the registry (§4) with neutral defaults, so old vectors decode with the new dimensions at their defaults; a new normative section with MUST-level rules (the composition grammar of §7 entered at 1.1.0). A Y release is additive.
• Z — minor change. Everything that leaves P and the pure decode of P untouched: clarification, wording and non-semantic fixes; additions to the hyper-condition set (§3.4) and refinements of a hyper condition's domain whose earlier form remains valid (owner policy, 2026-07-16; anchor at 1.0.1, the viseme map at 1.1.1) — they ride alongside P without adding axes, so old vectors and pure-latent decoders are unaffected; grammar constructs added to §7 that keep every earlier script valid (1.1.1 and 1.1.2); decode refinements that keep the vector layout, ids, ranges and defaults (the updated arm axes definition of §4.1 at 1.1.2). A minor change MAY alter rendered geometry on some avatars; storage compatibility does not imply identical geometry, and the change log MUST record such an effect.

Rules that hold across releases:

• Within one X, an id is never reused for a different meaning, no axis is removed or redefined, and the registry order of existing ids never changes.
• Consumers MUST ignore unknown ids (§5), so a vector written under a later Y or Z of the same X decodes under an earlier one with the new dimensions dropped, and a vector written under an earlier release decodes under a later one with defaults substituted.
• Each release records supersedes and compatibility (baseline | additive | breaking). Implementers SHOULD advertise the exact version they target, and conformance is always stated against one version (§6).
• Release and numbering of a version are declared by the owner; a Since tag inside §7 names the tier a construct entered and is not a separately published version.

Release history: 1.0.0 (baseline) → 1.0.1 (minor: anchor) → 1.1.0 (major: composition grammar introduced) → 1.1.1 (minor) → 1.1.2 (minor, current). The full record is the change log page, ipl.signthai.com/changelog/.