Releases y versionado
Las notas de cada versión están en la página de GitHub Releases, con un feed Atom al que puedes suscribirte. Esta página documenta cómo funcionan los releases — qué significa un número de versión, qué incluye cada uno y cómo verificarlo o revertirlo — en lugar de repetir unas notas que quedarían obsoletas.
El release actual es la v3.0.0.
Qué significa el número de versión
Sección titulada «Qué significa el número de versión»El versionado es semántico y, en este proyecto, la frontera relevante es la superficie MCP: las herramientas, acciones, recursos, prompts y opciones de configuración de las que depende un cliente.
| Cambio | Ejemplo | Incremento |
|---|---|---|
| Correcciones y trabajo interno sin cambio de interfaz | Un handler devuelve un error más claro | Parche |
| Nuevas acciones, herramientas, recursos o prompts | Un dominio de la API de GitLab gana cobertura | Menor |
| Nueva configuración opcional | Se añade un flag con un valor por defecto seguro | Menor |
| Retirar un parámetro, una combinación de parámetros o un campo de respuesta que la herramienta no podía honrar | Un cursor que el campo de GitLab rechaza | Menor |
| Eliminar una acción o cambiar un parámetro obligatorio | Se renombra un ID de acción | Mayor |
Lo habitual son releases aditivos. Un incremento menor puede cambiar cuántas herramientas ves —el catálogo crece— pero no invalida una llamada que ya funcionaba.
La única excepción es la fila de retirada, y es deliberada. Cubre tres formas de un mismo fallo, y cualquiera de ellas puede repararse sin esperar a una versión mayor. Un parámetro que la herramienta publicaba pero que el endpoint de GitLab detrás nunca leía se respondía descartándolo, así que la llamada devolvía una página que nadie había pedido y ningún error. Una combinación de parámetros que el endpoint rechaza, como un tamaño de página hacia delante y otro hacia atrás a la vez, se respondía eligiendo uno en silencio. Un campo de respuesta sobre el que ningún parámetro de esa herramienta puede actuar, como un cursor de una página que no va a servir, ofrecía un siguiente paso que no existe. Retirar cualquiera de las tres sustituye una respuesta silenciosamente incorrecta por una honesta: un rechazo que nombra el parámetro rechazado, o una respuesta que deja de ofrecer un paso que la herramienta no puede dar. Esa es la razón de hacerlo y no un efecto colateral, porque una respuesta silenciosamente incorrecta es peor que una rechazada. Cualquier release que retire uno nombra las herramientas afectadas en sus notas.
Qué incluye cada release
Sección titulada «Qué incluye cada release»| Artefacto | Detalle |
|---|---|
| Binarios | Linux, macOS y Windows; amd64 y arm64; más una build universal de macOS |
| Imagen de contenedor | GHCR y Docker Hub |
| Extensión para Claude Desktop | Un paquete .mcpb de un clic |
| Paquetes npm | @jmrp.io/gitlab-mcp-server más un paquete de binario por plataforma |
| Checksums | checksums.txt con el hash SHA-256 de cada binario |
| Firma | checksums.txt.sigstore.json — bundle keyless de Cosign/Sigstore, sin claves que traer |
| SBOM | Un documento SPDX por binario (<artefacto>.sbom.json) |
| Procedencia | Atestaciones SLSA de build, verificables con gh attestation verify |
Los pasos de verificación están en la página de seguridad. Si la verificación falla, no ejecutes el binario.
Mantenerse al día
Sección titulada «Mantenerse al día»Dos formas de enterarte de un release:
- Observa el repositorio en GitHub con el filtro de Releases, para recibir una notificación por versión.
- Suscríbete al feed Atom desde un lector de feeds o desde tu automatización.
Instalarlo es después un paso aparte y deliberado. El servidor no comprueba si hay actualizaciones ni reemplaza nunca su propio binario, así que una actualización pasa por el canal con el que lo instalaste (npm update, brew upgrade, winget upgrade, una etiqueta de imagen más nueva, una extensión para Claude Desktop más nueva) o por descargar el nuevo asset desde la página de Releases.
Fijar versión y revertir
Sección titulada «Fijar versión y revertir»Todos los releases publicados siguen descargables, así que revertir es simplemente descargar el asset anterior para tu plataforma, o fijar la etiqueta de imagen previa si usas el contenedor.
En entornos donde una actualización inesperada sería disruptiva, fija una versión exacta en lugar de latest. Eso es todo: el binario no puede sustituirse a sí mismo entre ejecuciones, así que la versión que fijaste es la que sigue ejecutándose hasta que la actualices.
Preguntas frecuentes
¿Dónde está el changelog de GitLab MCP Server?
Las notas de versión están en la página de GitHub Releases, una entrada por versión, generadas a partir de los commits de ese release. También hay un feed Atom en https://github.com/jmrplens/gitlab-mcp-server/releases.atom al que puede suscribirse cualquier lector de feeds o automatización. Esta página documenta el proceso de publicación en sí — qué significa un número de versión, qué incluye cada release y cómo verificar una descarga — en lugar de duplicar unas notas que quedarían obsoletas.
¿Cómo versiona GitLab MCP Server sus releases?
Sigue versionado semántico. El número de parche cambia con correcciones y trabajo interno que no altera la interfaz. El número menor cambia cuando se añaden herramientas, acciones, recursos o prompts, o cuando la configuración gana una opción: cambios aditivos que dejan funcionando las llamadas existentes. Hay un caso concreto que no es aditivo y sigue siendo menor: retirar un parámetro, una combinación de parámetros o un campo de respuesta que el endpoint de GitLab detrás de la herramienta no podía honrar, porque lo que se publicaba se respondía con la página equivocada en lugar de con un error. El número mayor solo cambia ante una ruptura de la superficie MCP o de la configuración, como eliminar una acción o cambiar un parámetro obligatorio.
¿Qué publica cada release?
Cada release publica binarios para Linux, macOS y Windows en amd64 y arm64, un binario universal de macOS, una imagen de contenedor en GHCR y Docker Hub, una extensión para Claude Desktop (.mcpb), los paquetes npm y checksums.txt. Los checksums se firman sin claves con Cosign/Sigstore, cada binario lleva su SBOM en formato SPDX y los artefactos del release llevan atestaciones de procedencia SLSA, así que puedes verificar lo que has descargado antes de ejecutarlo.
¿Cómo me entero de los nuevos releases?
De dos formas. Observa el repositorio en GitHub con el filtro de Releases, o suscribe un lector de feeds a https://github.com/jmrplens/gitlab-mcp-server/releases.atom. Instalar un release es después un paso que das tú: el servidor no comprueba si hay actualizaciones ni reemplaza nunca su propio binario, así que actualizas por el canal con el que lo instalaste (npm, Homebrew, winget, una etiqueta de imagen más nueva, una extensión para Claude Desktop más nueva) o descargas el nuevo asset desde la página de Releases.
¿Cómo vuelvo a una versión anterior?
Todos los releases siguen descargables desde la página de GitHub Releases, así que revertir consiste en descargar el asset anterior para tu plataforma y sustituir el binario, o fijar la etiqueta de imagen anterior si usas el contenedor. En entornos donde una actualización inesperada sería disruptiva, fija una versión exacta en lugar de latest. No hace falta nada más: el servidor no reemplaza nunca su propio binario, así que una versión fijada se queda donde está hasta que la actualices tú.