Versioning and deprecation policy
How the Xverum MCP server is versioned, what counts as a breaking change, and how deprecations are announced.
Versioning scheme
The Xverum MCP server uses Semantic Versioning (semver).
- Major (e.g., 2.0.0 → 3.0.0): breaking changes — a tool removed, a response field type changed, a required parameter added
- Minor (e.g., 2.2.0 → 2.3.0): new features — a new tool added, new optional response fields, new optional parameters
- Patch (e.g., 2.2.1 → 2.2.2): fixes — corrected metadata, documentation updates, registry alignment
The version is tracked in server.json and published to the MCP Registry as com.xverum/mcp.
The npm wrapper package (@xverum/mcp) has its own version in package.json. It follows semver independently — a wrapper update does not change the server version, and vice versa.
What counts as a breaking change
| Breaking | Non-breaking |
|---|---|
| Removing a tool | Adding a new tool |
| Removing a required response field | Adding optional fields to responses |
| Changing a response field's type | Adding optional parameters |
| Adding a new required parameter | Relaxing a constraint (e.g., raising a limit) |
| Changing the authentication method | Adding new error codes |
Deprecation policy
We announce deprecations at least 90 days before removal.
Deprecated features are communicated via:
- The CHANGELOG.md in this repository
- GitHub Releases
- A
SunsetHTTP header on affected responses (where applicable)
Recent deprecations
| What | Deprecated | Replacement | Removed |
|---|---|---|---|
npm package xverum-mcp | 2026-09-09 | @xverum/mcp — run npx @xverum/mcp | Not yet (npm redirects automatically) |
Where changes are announced
- CHANGELOG.md — every release
- GitHub Releases — tagged releases with notes
- MCP Registry — version bumps on
com.xverum/mcp