Releases and versioning
Release notes for every version live on the GitHub Releases page, with an Atom feed you can subscribe to. This page documents how releases work — what a version number means, what each one ships, and how to verify or roll one back — rather than repeating notes that would go stale.
The current release is v3.0.0.
What the version number means
Section titled “What the version number means”Versioning is semantic, and for this project the interesting boundary is the MCP surface: the tools, actions, resources, prompts and configuration options a client depends on.
| Change | Example | Version bump |
|---|---|---|
| Fixes and internal work with no interface change | A handler returns a clearer error | Patch |
| New actions, tools, resources or prompts | A GitLab API domain gains coverage | Minor |
| New optional configuration | A flag is added with a safe default | Minor |
| Withdrawing a parameter, a combination of parameters, or a response field a tool could not honor | A cursor the GitLab field rejects | Minor |
| Removing an action, or changing a required parameter | An action ID is renamed | Major |
Additive releases are the common case. A minor bump can change how many tools you see — the catalog grows — but it does not invalidate a call that already worked.
The one exception is the withdrawal row, and it is deliberate. It covers three shapes of one fault, all of which a release may repair without waiting for a major version. A parameter a tool published but the GitLab endpoint behind it never read was answered by discarding it, so the call returned a page nobody asked for and no error. A combination of parameters the endpoint refuses, such as a forward and a backward page size together, was answered by silently picking one of them. A response field no parameter of that tool can act on, such as a cursor for a page it will not serve, offered a next step that does not exist. Withdrawing any of the three replaces a silently wrong answer with an honest one: a refusal naming the parameter it rejected, or a response that stops offering a step the tool cannot take. That is the reason to do it rather than a side effect, because a silently wrong answer is worse than a refused one. Any release that withdraws one names the tools in its notes.
What each release ships
Section titled “What each release ships”| Artifact | Detail |
|---|---|
| Binaries | Linux, macOS and Windows; amd64 and arm64; plus a macOS universal build |
| Container image | GHCR and Docker Hub |
| Claude Desktop extension | A one-click .mcpb package |
| npm packages | @jmrp.io/gitlab-mcp-server plus a per-platform binary package |
| Checksums | checksums.txt with the SHA-256 hash of every binary |
| Signature | checksums.txt.sigstore.json — a keyless Cosign/Sigstore bundle, no key to fetch |
| SBOMs | One SPDX document per binary (<asset>.sbom.json) |
| Provenance | SLSA build attestations, verifiable with gh attestation verify |
Verification steps are on the security page. If verification fails, do not run the binary.
Staying current
Section titled “Staying current”Two ways to hear about a release:
- Watch the repository on GitHub with the Releases filter, for a notification per version.
- Subscribe to the Atom feed from a feed reader or from automation.
Installing one is a separate and deliberate step. The server does not check for updates and never replaces its own binary, so an upgrade goes through whichever channel installed it (npm update, brew upgrade, winget upgrade, a newer image tag, a newer Claude Desktop extension) or through downloading the new asset from the Releases page.
Pinning and rolling back
Section titled “Pinning and rolling back”Every published release stays downloadable, so a rollback is just fetching the previous asset for your platform, or pinning the previous image tag if you run the container.
In environments where an unexpected upgrade would be disruptive, pin an exact version instead of latest. That is the whole of it: the binary cannot replace itself between runs, so the version you pinned is the version that keeps running until you upgrade it.
Frequently asked questions
Where is the GitLab MCP Server changelog?
Release notes live on the GitHub Releases page, one entry per version, generated from the commits in that release. There is also an Atom feed at https://github.com/jmrplens/gitlab-mcp-server/releases.atom that any feed reader or automation can subscribe to. This page documents the release process itself — what a version number means, what each release ships, and how to verify a download — rather than duplicating notes that would fall out of date.
How does GitLab MCP Server version its releases?
It follows semantic versioning. The patch number changes for fixes and internal work with no interface change. The minor number changes when tools, actions, resources or prompts are added, or when configuration gains an option — additive changes that leave existing calls working. One narrow case is not additive and is still minor: a parameter, a combination of parameters, or a response field that the GitLab endpoint behind a tool could not honor may be withdrawn, because what was published was answered with the wrong page rather than an error. The major number changes only for a breaking change to the MCP surface or to configuration, such as removing an action or changing a required parameter.
What does each release publish?
Every release publishes binaries for Linux, macOS and Windows on both amd64 and arm64, a macOS universal binary, a container image on GHCR and Docker Hub, a Claude Desktop extension (.mcpb), the npm packages, and checksums.txt. The checksums are signed keylessly with Cosign/Sigstore, every binary ships an SPDX SBOM, and the release artifacts carry SLSA build provenance attestations, so you can verify what you downloaded before running it.
How do I get notified about new GitLab MCP Server releases?
Two ways. Watch the repository on GitHub with the Releases filter, or subscribe a feed reader to https://github.com/jmrplens/gitlab-mcp-server/releases.atom. Installing a release is then a step you take: the server does not check for updates and never replaces its own binary, so you upgrade through whichever channel installed it (npm, Homebrew, winget, a newer image tag, a newer Claude Desktop extension) or download the new asset from the Releases page.
How do I roll back to an earlier version?
Every release remains downloadable from the GitHub Releases page, so rolling back means fetching the previous asset for your platform and replacing the binary, or pinning the previous image tag if you run the container. In environments where an unexpected upgrade would be disruptive, pin an exact version rather than latest. Nothing else is needed: the server never replaces its own binary, so a pinned version stays put until you upgrade it yourself.