API versioning

This page describes Parsoid versions specified in the Specs page hierarchy. See T124365 for background about how/why this was added.

Global API version
The global API version is part of the path. Example:. Following the principles of semantic versioning, it is incremented when a stable end point is changed in a backwards-incompatible manner. Since this is a disruptive event, we try hard to avoid breaking stable end points.

End point stability
Each API end point is marked with a stability class: Stable, unstable or experimental. Typically, API end points start out as experimental or unstable, and over time graduate to become part of the stable API.

Stable
Stable end points are guaranteed to not change in incompatible ways. This means that you can be sure that the basic interface as documented by the spec will continue to work as described.

Unstable
End points marked as unstable can change in incompatible ways without incrementing the major API version, but they will increment minor versions. We will reach out to users and make a concerted effort to avoid breaking existing consumers.

Experimental
Experimental end points can change in incompatible ways at any time, without incrementing the API version. You are welcome to use them at your own risk.

Content format stability and -negotiation
Changes in the structure of the returned content will be clearly indicated by a change in the profile part of the mime type: text/html; charset=utf-8; profile=" https://www.mediawiki.org/wiki/Specs/HTML/1.2.1 " For longer-term output format stability, you should send an  header with the mime type you expect: Accept: text/html; charset=utf-8; profile=" https://www.mediawiki.org/wiki/Specs/HTML/1.2.1 " In case of output format changes, the API will then continue to respond with the requested format, even if a newer format is available. Support for old output formats will normally be maintained until usage drops below a low threshold. Phased-out formats will be announced with ample warning on the API-announce list.

Background: How we interpret semver in format negotiations
Our profile URLs generally end with a version number based on the semver semantic versioning scheme. In semantic versioning, all backwards-incompatible changes trigger an increment of the major version number (ex: 1.2.1 to 2.0.0). As the goal of our format negotiation mechanism is to avoid breaking clients, this is what we are focusing on. Clients are encouraged to provide the exact version they tested with, but the API will typically return the latest content-type that is compatible with the requested major version.