Skip to main content
OpenClaw propose quatre canaux de mise à jour :
  • stable : dist-tag npm latest. Recommandé pour la plupart des utilisateurs.
  • extended-stable : dist-tag npm extended-stable. Nouveau canal de paquets pour un mois antérieur encore pris en charge. Il concerne uniquement les paquets et l’installation s’effectue uniquement au premier plan. Une sélection enregistrée reçoit des indications de mise à jour en lecture seule lorsque update.checkOnStart est activé, mais celles-ci ne sont jamais appliquées automatiquement.
  • beta : dist-tag npm beta. Se rabat sur latest lorsque beta est absent ou antérieur à la version stable actuelle.
  • dev : tête mobile de main (git). Dist-tag npm dev lorsqu’il est publié. main est destiné à l’expérimentation et au développement actif ; il peut contenir des fonctionnalités incomplètes ou des changements incompatibles. Ne l’utilisez pas pour des Gateway de production.
Les versions stables sont généralement d’abord publiées sur beta, y sont validées, puis sont promues vers latest sans changement de version. Les mainteneurs peuvent également publier directement sur latest. Les dist-tags constituent la source de vérité pour les installations npm.

Changement de canal

--channel enregistre le choix dans update.channel dans la configuration et pilote les deux modes d’installation : Pour les installations git dev, la copie de travail par défaut est ~/openclaw (ou $OPENCLAW_HOME/openclaw lorsque OPENCLAW_HOME est défini) ; utilisez OPENCLAW_GIT_DIR pour la remplacer.
Pour conserver stable et dev en parallèle, utilisez deux copies de travail distinctes et faites pointer chaque Gateway vers la sienne.

Ciblage ponctuel d’une version ou d’un tag

Utilisez --tag pour cibler un dist-tag, une version ou une spécification de paquet précis lors d’une seule mise à jour, sans modifier le canal enregistré :
Remarques :
  • --tag s’applique uniquement aux installations par paquet (npm) ; les installations git l’ignorent.
  • Le tag n’est pas enregistré ; la prochaine commande openclaw update utilise le canal configuré.
  • --tag main correspond à la spécification compatible npm github:openclaw/openclaw#main pour cette seule exécution. Pour une installation persistante suivant la branche mobile main, utilisez openclaw update --channel dev (les installations par paquet passent à une copie de travail git) ou réinstallez avec la méthode git du programme d’installation : curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git --version main. Le mode d’installation npm rejette explicitement les cibles provenant de GitHub/git et vous oriente à la place vers la méthode git.
  • Protection contre les rétrogradations : si la version cible est antérieure à la version actuelle, OpenClaw demande une confirmation (ignorez-la avec --yes).
  • Extended-stable utilise toujours sa cible de paquet exacte vérifiée. Il ne s’agit pas d’un alias ponctuel de --tag extended-stable, et --tag ne peut pas être combiné avec un canal extended-stable effectif.
  • --channel beta diffère de --tag beta : le flux du canal peut se rabattre sur stable/latest lorsque la bêta est absente ou antérieure, tandis que --tag beta cible toujours le dist-tag beta brut pour cette seule exécution.

Simulation

Prévisualisez les actions qu’effectuerait openclaw update sans apporter de modifications :
La simulation indique le canal effectif, la version cible, les actions prévues et si une confirmation de rétrogradation serait requise.

Plugins et canaux

Le changement de canal avec openclaw update synchronise également les sources des Plugins :
  • dev fait repasser les Plugins installés qui disposent d’un équivalent intégré vers leur source intégrée (copie de travail git).
  • stable et beta restaurent les paquets de Plugins installés via npm ou ClawHub.
  • extended-stable associe les Plugins npm officiels admissibles ayant une intention nue/par défaut ou latest à la version exacte du cœur installée. Il n’interroge pas les tags @extended-stable des Plugins lors de l’exécution.
  • Les Plugins installés via npm sont mis à jour après la fin de la mise à jour du cœur.

Vérification de l’état actuel

Affiche le canal actif (avec la source qui l’a déterminé : configuration, tag git, branche git, version installée ou valeur par défaut), le type d’installation (git ou paquet), la version actuelle et la disponibilité d’une mise à jour.

Bonnes pratiques de balisage

  • Balisage des versions sur lesquelles les copies de travail git doivent aboutir : vYYYY.M.PATCH pour stable, vYYYY.M.PATCH-beta.N pour beta. Les suffixes de préversion nommés comme -alpha.N, -rc.N et -next.N ne sont pas des cibles stables ou bêta.
  • Les anciens tags stables numériques comme vYYYY.M.PATCH-1 et v1.0.1-1 restent reconnus comme tags git stables à des fins de compatibilité.
  • vYYYY.M.PATCH.beta.N (séparé par des points) est également reconnu à des fins de compatibilité ; privilégiez -beta.N.
  • Conservez les tags immuables : ne déplacez et ne réutilisez jamais un tag.
  • Les dist-tags npm restent la source de vérité pour les installations npm :
    • latest -> stable
    • extended-stable -> version de paquet du mois antérieur encore pris en charge
    • beta -> version candidate ou version stable publiée d’abord en bêta
    • dev -> instantané de main (facultatif)

Disponibilité de l’application macOS

Les versions bêta et dev peuvent ne pas inclure de version de l’application macOS. Ce n’est pas un problème :
  • Le tag git et le dist-tag npm peuvent tout de même être publiés séparément.
  • Indiquez « aucune version macOS pour cette bêta » dans les notes de version ou le journal des modifications.

Voir aussi