---
title: Versiones y estabilidad
description: Qué sigue funcionando en un release 1.x de Hollware, qué no promete, y cómo lo verifica el repositorio.
section: reference
order: 2
---

# Versiones y estabilidad

Hollware sigue versionado semántico desde la 1.0.0. Un release minor o patch mantiene funcionando todo lo que un agente, un sitio, un script o un proyecto construyó sobre una 1.x anterior; solo un release major puede romperlo. Todos los paquetes de Hollware llevan la misma versión, así que `@hollware/server@1.4.0` y `@hollware/nuxt@1.4.0` van juntos.

## Qué cubre la promesa

1. **Las herramientas MCP:** sus nombres, los scopes que pide cada una, sus schemas de entrada y salida, y la forma de un error.
2. **La API de lectura** en `/v1`: sus rutas, parámetros y respuestas, tal como lo dice su documento OpenAPI en `/v1/openapi.json`.
3. **El entrypoint RPC** `Hollware` de un service binding: sus métodos y sus firmas.
4. **Los eventos de webhooks:** sus tipos y campos, y cómo se firman (`verifyWebhook`).
5. **La CLI** `hollware`: sus comandos y flags.
6. **Los exports** de cada paquete publicado: cada nombre, valor y tipo.
7. **Las migraciones** que publicó un release: nunca se modifican ni se eliminan, solo se agregan nuevas después.

## Qué puede agregar un release minor

Una herramienta, ruta, método, comando, flag, export o tipo de evento nuevo; una entrada opcional nueva; un campo nuevo en una respuesta o un evento; un valor nuevo de `outcome` o del `kind` de un evento. Escribe tu código para que los tolere: un outcome que no conoce es una respuesta sobre la que no actúa, y un tipo de evento que no conoce se ignora.

## Qué no cubre

Las pantallas del admin y sus rutas bajo `/v1/admin`, que solo usa el admin; el texto de los mensajes, las correcciones sugeridas y las descripciones; los logs; y todo lo que un paquete no exporta. Lee el `code` de un error, nunca su `message`.

## Cómo lo verifica el repositorio

La API pública vive en `api/` del repositorio, tal como la genera el código, y una prueba falla cuando ambos difieren, así que cada cambio de la API aparece en el cambio que lo provoca. Desde el primer release candidate de la 1.0, el CI compara `api/` con el release más reciente y falla ante cualquier cosa que lo rompa: una entrada más estricta, una respuesta que pierde un campo, un scope nuevo que pide una herramienta, una migración modificada.

## Release candidates

La 1.0 llega a través de release candidates, `1.0.0-rc.N`, publicados en npm con el tag `rc`: `npm install hollware@rc`. Cada candidate mantiene la promesa del anterior. Todos los releases, candidates incluidos, se publican desde CI con procedencia de npm.