As onX evolves, implementers need clear expectations around backwards compatibility, breaking changes, and versioning.
Currently, the onX standard does not define how:
- Changes to message schemas are versioned
- Breaking vs non-breaking changes are handled
- Implementations should safely evolve over time
This creates uncertainty for early adopters and increases the risk of fragmentation or accidental breakage as the standard matures.
This task proposes defining backwards compatibility and versioning guidelines that:
- Establish clear principles for evolving onX
- Minimize breaking changes for implementers
- Allow the standard to grow without stagnation
- Provide confidence to brands and vendors adopting onX in production
As onX evolves, implementers need clear expectations around backwards compatibility, breaking changes, and versioning.
Currently, the onX standard does not define how:
This creates uncertainty for early adopters and increases the risk of fragmentation or accidental breakage as the standard matures.
This task proposes defining backwards compatibility and versioning guidelines that: