Ejecutas hermes update el miércoles por la mañana como siempre, esperando que se traiga las pocas docenas de commits que aterrizaron en main. En lugar de eso imprime una sola línea: ✓ No newer release: stable v0.21.6; this checkout is newer and waits for the next release… — y menciona que vas un par de cientos de commits por detrás de main. No has tocado ni un solo ajuste.

Nada está roto. Lo que cambió fue el valor por defecto: en una instalación oficial desde código fuente, hermes update ahora sigue el canal stable — la última release publicada en GitHub — en lugar de cada commit de main. Estas son las nuevas reglas, incluida la que pilla a la gente por sorpresa: el valor por defecto solo avanza hacia delante.

A qué apunta realmente “stable”

Stable es la GitHub Release publicada más reciente del repositorio oficial, y tiene que cumplir tres cosas a la vez:

• no es un draft ni una prerelease;
• su tag es una versión semántica estricta, vX.Y.Z — tres números, sin sufijo.

Cuando se cumple, el objetivo de la actualización es el commit exacto al que apunta ese tag, no la punta actual de la rama en la que el tag esté situado. Así nunca te desvías lateralmente hacia código a medio terminar entre dos actualizaciones.

Un detalle de historia merece conocerse: el proyecto antes publicaba tags basados en fecha (v2026.9.24 y compañía). Solo las versiones semánticas son elegibles para el feed stable, lo que significa que un tag CalVer nunca puede confundirse con una release.

Dónde vive el canal: por instalación, no global

El registro del canal se escribe en config.yaml, pero deliberadamente no como un update.channel global:

update:
  installs:
    a4f3b2c1d0e9f8a7:                      # id de instalación (sha16 de la ruta raíz de la instalación)
      path: /home/u/.hermes/hermes-agent
      channel: stable

¿Por qué ese salto extra? Porque es habitual que varias instalaciones compartan un mismo ~/.hermes — Hermes en el host, un gateway en Docker y la app de escritorio pueden hacer bind-mount de la misma configuración. Con un único interruptor global, pasar tu checkout de desarrollo a canary también cambiaría el feed de actualización de la app de escritorio.

Para ver la identidad y la ruta de esta instalación:

hermes update --install-id

Tres comandos, no los mezcles

Comando	Qué hace
hermes update	Aplica una actualización en el canal de esta instalación
hermes update --check	Compara con el objetivo sin hacer pull, instalar ni reiniciar
hermes update --plan	Imprime el plan: tipo de instalación (git/Docker/Nix/apt) y cada servicio en ejecución con su supervisor
hermes update --set-channel stable	Persiste el canal para esta instalación; por sí mismo no actualiza nada
hermes update --channel main	Afecta solo a esta ejecución; no se guarda nada
hermes update --install-id	Imprime la identidad y la ruta de esta instalación

El par que se confunde es --set-channel frente a --channel: el primero escribe configuración, el segundo se evapora cuando termina el comando. Si solo quieres echar un vistazo a lo que tiene main, con --channel main basta y no cambiará el comportamiento futuro.

La regla que sorprende: el valor por defecto solo avanza

El cambio de valor por defecto se hizo de forma conservadora, y la regla es que una instalación que nunca eligió canal solo avanza hacia delante:

• si tu checkout ya contiene la última release — por ejemplo, seguías main y ya ibas por delante — se queda donde está hasta que se publique una release más nueva;
• solo un --set-channel stable explícito cuenta como consentimiento para aterrizar en el commit exacto de la release, incluso cuando eso significa retroceder.

Esa regla cubre --check, la ruta de aplicación y la comprobación pasiva que usan la app de escritorio y el banner de actualización. No te van a degradar en silencio con una actualización despistada, y tampoco te vas a quedar anclado al código antiguo para siempre.

Dos tipos de instalación quedan intactos:

• los forks y los mirrors mantienen main. No tienen releases oficiales, así que no hay ningún stable al que seguir;
• las instalaciones empaquetadas (MSIX, Store, bundled, electron-updater, de gestión externa) llevan su canal fijado en el momento de la compilación y no pueden cambiarlo.

Escritorio: un nuevo interruptor en Settings → About

En una instalación desde código fuente, la app de escritorio ahora muestra una fila Update channel bajo Settings → About → Updates, que te permite alternar entre Stable releases y Every commit. Solo aparece en instalaciones desde código fuente (posix-handoff / windows-handoff); las instalaciones empaquetadas nunca la ven, porque su canal es fijo.

El detalle de interacción está bien pensado:

• main → stable pregunta primero, porque ese paso puede llevarte a código más antiguo;
• stable → main cambia al instante, porque nunca puede llevarte hacia atrás.

La GUI y la CLI escriben el mismo registro, así que un cambio hecho en la app es visible de inmediato para hermes update --check.

Tres arreglos que vinieron con el cambio

Aterrizaron también varios arreglos de acompañamiento, y los tres merecen conocerse:

1. La consulta de stable salía sin autenticar y chocaba con el límite de peticiones anónimo. El código antiguo leía releases/latest con una llamada HTTP pelada que no llevaba credencial alguna, gastando el cupo anónimo de GitHub de 60 peticiones por hora incluso cuando GH_TOKEN estaba definido o gh tenía sesión iniciada. Detrás de una IP de salida compartida de oficina, CI o Docker ese cupo se agota rápido, y el 403 resultante se mostraba como ✗ Could not resolve the stable source channel: No published stable release could be verified — que se lee como «no hay ninguna release en absoluto». Ahora la consulta recorre la escalera de tokens (entorno, luego gh auth token, luego anónimo) e informa un límite de peticiones como lo que es, con su hora de reinicio y, para quienes llaman de forma anónima, una sugerencia de definir GITHUB_TOKEN. Una consulta fallida sigue deteniéndose donde está y nunca toca el checkout.

2. Los checkouts superficiales u offline nunca se arrastran hacia atrás. Si un clon shallow o una copia offline ya es más nueva que la última release, una actualización ya no la «corrige» hacia esa release.

3. Un fallo de dependencias de Node exclusivo de la app de escritorio ya no se lleva por delante la TUI y la web UI. Este importa en máquinas headless. npm ci instala ui-tui, web y apps/desktop como una sola unión, y solo la app de escritorio arrastra addons nativos (node-pty, electron) que necesitan un compilador. Así que un servidor Ubuntu con g++ 9 — que rechaza -std=gnu++20 — hacía fallar toda la instalación de dependencias, la TUI y la web UI nunca se construían, y cada arranque imprimía a source update could not be finished automatically (6 attempts). Ahora la instalación reintenta una vez sin la app de escritorio, construye la TUI y la web UI como siempre y registra la compilación del escritorio como pendiente: Desktop app build owed: desktop dependencies failed. También imprime una salida realmente útil: si esta máquina nunca ejecuta la app de escritorio, hermes uninstall --gui la elimina del checkout para que las futuras actualizaciones dejen de compilar sus dependencias nativas.

¿Cuál deberías elegir?

• Quieres estabilidad (el valor por defecto, y lo que quiere la mayoría): no hagas nada, sigue ejecutando hermes update.
• Quieres la última frontera: hermes update --set-channel main recupera el comportamiento antiguo de seguir commit a commit.
• Solo quieres mirar: hermes update --channel main --check no cambia nada a largo plazo.
• No sabes en qué canal estás: la primera línea de hermes update --check te lo dice.

Una advertencia si desarrollas en tu propio fork: las releases oficiales no son tuyas, así que tu valor por defecto sigue siendo main. Es la decisión correcta: la fuente de actualización de un fork debe ser decisión suya.

La versión corta

Este cambio convierte las actualizaciones de un flujo continuo en una escalera con límites de versión: moverse solo entre releases publicadas, no retroceder por defecto, mantener la elección por instalación y autenticar la consulta como tú. Si ejecutas hermes update a diario, solo hay tres cosas que recordar: stable es el valor por defecto, solo --set-channel persiste, y main hay que pedirlo.

Para el panorama más amplio, empieza por nuestra referencia del comando hermes update, el artículo anterior sobre actualizaciones sin sorpresas y qué hacer cuando una actualización te llena el disco. La release actual es v0.21.6; si aún no has instalado Hermes, la guía de instalación es el punto de partida.