Publicar una versión nueva de un plugin de Claude Code: version, changelog y plugin update

Hola, bienvenido. En esta lección vamos a publicar la primera versión nueva del plugin team, la 1.1.0, que corrige el error que vio Lucía al abrir su primera sesión. Vamos a recorrer el ciclo completo de una versión, desde la rama hasta el tag, y después vamos a ver cómo llega al equipo y cómo hace el repo para pedirla.

En la lección anterior vimos el error de Lucía: doctor.sh usa jq en la línea 5 sin comprobar si existe, y en una máquina sin jq el hook falla al arrancar con doctor.sh: line 5: jq: command not found. Vimos también que un hook roto no puede avisar de que hay una versión nueva que lo corrige. Vamos a corregir el script y, para que el equipo esté al tanto de la versión nueva, al final de la lección vamos a subir TEAM_PLUGIN_MIN.

Cada versión del plugin sigue los mismos pasos, los que dejamos escritos en el CONTRIBUTING.md del marketplace:

1. Una rama desde main para el cambio.
2. El cambio, su entrada en el CHANGELOG.md del plugin y la version nueva en su plugin.json.
3. scripts/check.sh en verde y una pull request con 2 revisores.
4. El merge en main.
5. El tag de la versión, con claude plugin tag.

Fíjate en cuál es el paso que publica. La versión llega a quien actualiza en cuanto el merge deja la version nueva en main, porque Claude Code lee el marketplace de la rama principal del repo. El tag no publica nada: marca en el historial qué commit es cada versión, y es lo que usaremos para volver atrás cuando una versión salga mal. Por eso la revisión tiene que hacerse antes del merge, y no después. Si quieres repasar el flujo de rama, pull request y revisores, lo tienes en el curso Git para Profesionales↗ (se abre en una pestaña nueva).