Use this page with AI
Copy this into your coding assistant and add your request.
Read https://openiap.dev/commerce-protocol/versioning and https://openiap.dev/llms.txt. Follow the reading instructions, detailed reference, and linked guides relevant to my task before making changes.
Inspect my existing project and reuse its framework and conventions. Ask me for missing product decisions. Implement the requested behavior and run the applicable checks.
Show the working result, the commands and actual test results, and any remaining limitations. Keep your explanation brief.
My request: [describe what customers should be able to do]Versioning
Versions tell you whether two services still understand the same contract after an update. A minor update adds compatible information. A major update can require changes to your integration.
For example, adding an optional field to an open response can be minor: older callers ignore it. Renaming a field is normally major because those callers would no longer find the answer they expect. Before the npm package reaches 1.0.0, a wire member can be renamed without moving the protocol major; each such rename is listed with its migration note.
The protocol, each profile, and each binding version independently as MAJOR.MINOR, and callers pin on the major. The protocol version is separate from the npm package version. Open value spaces and open objects are what make MINOR additions safe: a consumer tolerates what it does not recognise instead of failing.
What changes what#
SPEC.md §12 has the full MAJOR/MINOR decision table and the list of renames made before 1.0.0. The REST path's v1 segment is the protocol major, so two majors can be served side by side during a migration.