Vous lancez hermes update le mercredi matin comme vous le faites toujours, en comptant récupérer la poignée de dizaines de commits arrivés sur main. À la place, il n’affiche qu’une seule ligne : ✓ No newer release: stable v0.21.6; this checkout is newer and waits for the next release… — et précise que vous avez quelques centaines de commits de retard sur main. Vous n’avez touché à aucun réglage.

Rien n’est cassé. La valeur par défaut a changé : sur une installation officielle depuis les sources, hermes update suit désormais le canal stable — la dernière release publiée sur GitHub — plutôt que chaque commit de main. Voici à quoi ressemblent les nouvelles règles, y compris celle qui prend les gens au dépourvu : la valeur par défaut ne va jamais que de l’avant.

Ce que « stable » désigne réellement

Stable, c’est la plus récente GitHub Release publiée dans le dépôt officiel, et elle doit satisfaire trois conditions à la fois :

• ce n’est ni un draft ni une prerelease ;
• son tag est une version sémantique stricte, vX.Y.Z — trois nombres, sans suffixe.

Quand c’est le cas, la cible de la mise à jour est le commit exact vers lequel ce tag pointe, et non la pointe actuelle de la branche sur laquelle le tag se trouve. Vous ne dérivez donc jamais latéralement vers du code à moitié terminé entre deux mises à jour.

Un épisode de l’histoire mérite d’être connu ici : le projet publiait autrefois des tags basés sur la date (v2026.9.24 et compagnie). Seules les versions sémantiques sont éligibles au feed stable, ce qui signifie qu’un tag CalVer ne peut jamais être pris pour une release.

Où vit le canal : par installation, pas de façon globale

L’enregistrement du canal est écrit dans config.yaml, mais délibérément pas sous la forme d’un update.channel global :

update:
  installs:
    a4f3b2c1d0e9f8a7:                      # identifiant d'installation (sha16 du chemin racine de l'installation)
      path: /home/u/.hermes/hermes-agent
      channel: stable

Pourquoi ce détour ? Parce qu’un même ~/.hermes est couramment partagé par plusieurs installations — Hermes sur l’hôte, un gateway dans Docker et l’application desktop peuvent tous monter en bind-mount la même config. Avec un interrupteur global unique, basculer votre checkout de développement vers canary basculerait aussi le feed de mise à jour de l’application desktop.

Pour voir l’identité et le chemin de cette installation :

hermes update --install-id

Trois commandes, ne les confondez pas

Commande	Ce qu’elle fait
hermes update	Applique une mise à jour selon le canal de cette installation
hermes update --check	Compare avec la cible sans pull, sans installation ni redémarrage
hermes update --plan	Affiche le plan : type d’installation (git/Docker/Nix/apt) et chaque service en cours d’exécution avec son superviseur
hermes update --set-channel stable	Persiste le canal pour cette installation ; ne met rien à jour en soi
hermes update --channel main	N’affecte que cette exécution ; rien n’est enregistré
hermes update --install-id	Affiche l’identité et le chemin de cette installation

Le duo que l’on confond, c’est --set-channel face à --channel : le premier écrit dans la config, le second s’évapore à la fin de la commande. Si vous voulez simplement jeter un œil à ce que propose main, --channel main suffit, et cela ne changera pas le comportement futur.

La règle qui surprend : la valeur par défaut ne va que de l’avant

Le changement de valeur par défaut a été fait de manière prudente, et la règle veut qu’une installation qui n’a jamais choisi de canal ne va que de l’avant :

• si votre checkout contient déjà la dernière release — mettons que vous suiviez main et que vous étiez en avance — il reste là où il est jusqu’à la publication d’une release plus récente ;
• seul un --set-channel stable explicite vaut consentement à atterrir sur le commit exact de la release, même lorsque cela implique de revenir en arrière.

Cette règle couvre --check, le chemin d’application et la vérification passive qu’utilisent l’application desktop et la bannière de mise à jour. Vous ne serez pas rétrogradé en silence par une mise à jour parasite, et vous ne serez pas non plus éternellement figé sur du vieux code.

Deux types d’installation ne sont pas concernés :

• les forks et les miroirs gardent main. Ils n’ont pas de releases officielles, donc pas de stable à suivre ;
• les installations packagées (MSIX, Store, bundled, electron-updater, gérées en externe) ont leur canal figé au moment du build et ne peuvent pas le modifier.

Desktop : un nouvel interrupteur sous Réglages → À propos

Sur une installation depuis les sources, l’application desktop affiche désormais une ligne Update channel sous Settings → About → Updates (Réglages → À propos → Mises à jour), qui vous laisse basculer entre les releases Stable et Every commit. Elle n’apparaît que pour les installations depuis les sources (posix-handoff / windows-handoff) ; les installations packagées ne la voient jamais, car leur canal est fixé.

Le détail de l’interaction est bien pensé :

• main → stable demande d’abord confirmation, parce que cette étape peut vous amener sur du code plus ancien ;
• stable → main bascule immédiatement, parce qu’elle ne peut jamais vous faire reculer.

L’interface graphique et la CLI écrivent le même enregistrement, donc un changement fait dans l’app est visible tout de suite par hermes update --check.

Trois correctifs livrés avec

Quelques correctifs d’accompagnement sont arrivés en même temps, et les trois valent la peine d’être connus :

1. La recherche de stable partait autrefois sans authentification et se heurtait à la limite de débit anonyme. L’ancien code lisait releases/latest avec un simple appel HTTP dépourvu de credential, consommant le quota anonyme de 60 requêtes par heure de GitHub même quand GH_TOKEN était défini ou que gh était connecté. Derrière une IP de sortie partagée — bureau, CI ou Docker — ce quota s’épuise vite, et le 403 qui en résultait était affiché sous la forme ✗ Could not resolve the stable source channel: No published stable release could be verified — ce qui se lit comme « il n’existe aucune release du tout ». La recherche parcourt désormais l’échelle des tokens (variable d’environnement, puis gh auth token, puis anonyme) et rapporte une limite de débit comme une limite de débit, avec son heure de réinitialisation et, pour les appelants anonymes, une indication d’utiliser GITHUB_TOKEN. Une recherche échouée s’arrête toujours là où elle est et ne touche jamais au checkout.

2. Les checkouts shallow ou hors ligne ne sont jamais ramenés en arrière. Si un clone shallow ou une copie hors ligne est déjà plus récent que la dernière release, une mise à jour ne le « corrige » plus en l’alignant sur cette release.

3. Une défaillance des dépendances Node propre au desktop n’entraîne plus le TUI et l’interface web dans sa chute. Ce point compte sur les hôtes headless. npm ci installe ui-tui, web et apps/desktop comme une seule union, et seule l’application desktop tire des addons natifs (node-pty, electron) qui nécessitent un compilateur. Un serveur Ubuntu avec g++ 9 — qui rejette -std=gnu++20 — faisait donc échouer toute l’installation des dépendances, le TUI et l’interface web n’étaient jamais construits, et chaque lancement affichait a source update could not be finished automatically (6 attempts). Désormais l’installation réessaie une fois sans l’application desktop, construit le TUI et l’interface web comme d’habitude, et enregistre le build du desktop comme dû : Desktop app build owed: desktop dependencies failed. Elle affiche aussi une porte de sortie réellement utile : si cet hôte n’exécute jamais l’application desktop, hermes uninstall --gui la retire du checkout pour que les mises à jour futures cessent complètement de compiler ses dépendances natives.

Laquelle choisir ?

• Vous voulez de la stabilité (la valeur par défaut, et ce que veut la plupart des gens) : ne faites rien, continuez à lancer hermes update.
• Vous voulez le bleeding edge : hermes update --set-channel main restaure l’ancien comportement, commit par commit.
• Vous voulez juste regarder : hermes update --channel main --check ne change rien sur le long terme.
• Vous ne savez pas sur quel canal vous êtes : la première ligne de hermes update --check vous le dit.

Une mise en garde si vous développez sur votre propre fork : les releases officielles ne sont pas les vôtres, donc votre valeur par défaut reste main. C’est le bon choix — la source de mise à jour d’un fork doit relever de sa propre décision.

En bref

Ce changement transforme la mise à jour d’un flux continu en un escalier aux frontières de versions : ne se déplacer qu’entre releases publiées, ne pas revenir en arrière par défaut, garder le choix par installation, et authentifier la recherche en tant que vous. Si vous lancez hermes update tous les jours, il n’y a que trois choses à retenir — stable est la valeur par défaut, seul --set-channel persiste, et main doit être demandé explicitement.

Pour la vue d’ensemble, commencez par notre référence de la commande hermes update, l’article plus ancien sur les mises à jour gracieuses, et que faire quand une mise à jour fait exploser votre disque. La release actuelle est la v0.21.6 ; si vous n’avez pas encore installé Hermes, le guide d’installation est l’endroit où commencer.