Después de v0.21.7, `hermes update` sigue solo los releases etiquetados — aprende en qué canal estás


Escribes hermes update, la terminal va soltando líneas y la última te dice que la actualización salió bien. Pero ¿qué instalaste realmente: un commit que entró ayer o un release cortado hace tres días? En una máquina que funciona sin parar esa pregunta importa: no quieres quedarte atrás de un arreglo ni despertar un día siguiendo main en un estado que nadie ha pisado todavía.

v0.21.7 trata exactamente de eso. No es un montón de funciones nuevas, es un cambio de política: una instalación desde fuente ahora se actualiza al último release publicado en lugar de hacerlo con cada commit de main. Este artículo cubre las dos partes prácticas: en qué canal está tu instalación y cómo comprobar qué estás ejecutando.

Qué cambió de verdad: de dónde vienen tus actualizaciones

Una instalación de Hermes vía git solía significar que hermes update llevaba el árbol de trabajo hasta la punta de main. Los arreglos llegaban rápido y, a la vez, caminabas sobre un suelo en movimiento: main cambia a diario, los estados a medio fusionar pueden durar horas y tu máquina podía actualizarse justo durante uno de ellos.

A partir de v0.21.7 el comportamiento por defecto es: avanzar solo al último release vX.Y.Z. Vale la pena leer las reglas una por una, porque moldean tu intuición sobre si estás atrasado:

  • Más antigua que el último tag → subes hasta ese tag.
  • Ya por delante del último tag (por ejemplo, porque antes seguías main) → no se mueve nada. Tu instalación se queda donde está y espera el siguiente release. Nunca se retrocede.
  • Forks y mirrors → siguen siguiendo main, sin cambios.
  • Microsoft Store, MSIX y la app de escritorio empaquetada → el empaquetado no cambia; se mueven con sus propias builds.

Esa segunda regla es la que la gente malinterpreta como «las actualizaciones están rotas». Es intencional: arrastrar una instalación que sigue main de vuelta a un tag convertiría una actualización de rutina en un downgrade, y Hermes no hace eso.

Canal A: Releases estables (el nuevo valor por defecto)

Nada que configurar: una instalación desde fuente arranca aquí. Obtienes el tag publicado más reciente, que ahora mismo es v0.21.7.

Para quién encaja: para cualquiera que prefiera que alguien más pise el suelo primero. Un release es un punto estable destilado de una ventana y no se convertirá en otra cosa de un día para otro.

Canal B: Cada commit (optar explícitamente)

Para seguir cada commit de main, un solo comando:

hermes update --set-channel main

Una vez configurado, vuelve el comportamiento antiguo. Volver atrás es el mismo tipo de comando:

hermes update --set-channel stable

Si tu build es anterior a estos flags, ejecuta primero un hermes update normal para obtener una versión que entienda canales, y luego cambia.

El canal es un estado persistente, no un flag de una sola actualización. Configúralo una vez y cada actualización posterior lo respetará, así que no lo dejes suelto en un script que vas a olvidar.

Dónde está el interruptor en la app de escritorio

En la app de escritorio está en Settings ▸ About ▸ Updates, que tiene un interruptor Update channel (Stable releases / Every commit). Solo significa algo para una instalación desde fuente: las instalaciones de Store, MSIX y empaquetadas no se ven afectadas por tu elección.

El diálogo de actualización también te dice en qué canal estás ahora, así que ya no tienes que confiar en «creo que lo configuré una vez».

Dos interrupciones cotidianas corregidas en el mismo release

Otros dos puntos del cuerpo del release entran en la categoría «no te importan hasta que te pasan»:

El razonamiento sobrevive al resume. Con modelos de razonamiento de Anthropic o Bedrock Converse, el thinking firmado se reinyecta correctamente después de hermes chat --resume y en el siguiente turno del gateway, y los modelos de razonamiento de Bedrock Converse ya no se rechazan en sesiones reanudadas. El mecanismo merece su propio análisis — qué rutas leen qué campos y qué pasa cuando una ruta rechaza un campo — y lo escribimos aparte: consulta la guía de replay de razonamiento.

Las actualizaciones ya no fallan detrás de algunos firewalls. Las instalaciones en main solían pedir un registro de release que firewalls regionales respondían con un 403, lo que hacía fallar la actualización por completo. Ahora la comprobación usa tu token de GitHub cuando hay uno configurado (GITHUB_TOKEN, o gh auth login), y reporta un límite de tasa de GitHub como tal en lugar de un fallo opaco.

Cuánto entró en esta ventana

Las cifras de escala provienen del cuerpo oficial del release, medidas en el commit 1fd18277267152893a8a24792b79213e7ca3f899:

Métrica Valor
Commits sin merge 740
Archivos cambiados 4,156 (+86,775 / −26,980)
PRs fusionados 204
Issues cerradas 69

Igual que con v0.21.6, las notas completas y curadas llegan con v0.22.0, que documentará todo desde v0.21.0 en adelante, incluyendo lo más destacado, las áreas de funcionalidad y los créditos completos de los colaboradores. El cuerpo de v0.21.7 también enumera un lote de cosas que aquí se dejan deliberadamente sin catalogar: plugins que ejecutan acciones integradas de la app, la burbuja pet del plugin SDK, skills instaladas a mitad de sesión que llegan al modelo sin reconstruir el prompt, Krea 2 Medium Turbo como la vía de imagen para suscriptores de pago con un fallback a FAL, actualizaciones de escritorio más rápidas, instalaciones fijadas que solo hacen checkout del pin, marcas de compactación emitidas a Relay, y nuevos plugins de la comunidad. Vamos cubriendo todo esto uno a uno: la pieza de acciones de plugins ya está publicada, acciones de plugins de escritorio y la burbuja pet.

Comprobar qué versión tienes

Tres comandos; elige el que corresponda a tu instalación:

# versión (una instalación git también imprime la distancia más allá del tag y el commit corto)
hermes version

# canal actual y origen de actualizaciones (instalaciones desde fuente)
hermes update --help

# instalaciones de escritorio / instalador
hermes doctor

Si sospechas que una actualización informó éxito pero no cambió nada, mira si el tag se movió en hermes version y luego lee hermes update --verbose. Para el contexto sobre los canales, consulta nuestra anterior guía del canal estable; para el pipeline de release con el que se cortó este tag, mira la nota del release v0.21.6.

Actualizar

# CLI
hermes update

# Escritorio: se actualiza solo. Microsoft Store: se actualiza desde la Store.

# Docker / Hermes Cloud
docker pull nousresearch/hermes-agent:stable

Una autocomprobación rápida después de actualizar, para que el canal y la versión sean los que esperas:

hermes version
hermes config get agent.max_turns      # también confirma que la actualización no tocó tu config

En una frase: v0.21.7 convierte la actualización de algo que vigilas sobre main en algo que puedes dejar tranquilo, al precio de saber en qué canal estás. Configúralo una vez y deja que el siguiente tag haga el resto.