Politique de publication
OpenClaw a trois voies publiques de publication :- stable : publications taguées qui publient vers npm
betapar défaut, ou vers npmlatestsur demande explicite - beta : tags de prépublication qui publient vers npm
beta - dev : la tête mobile de
main
Nommage des versions
- Version de publication stable :
YYYY.M.D- Tag Git :
vYYYY.M.D
- Tag Git :
- Version de publication corrective stable :
YYYY.M.D-N- Tag Git :
vYYYY.M.D-N
- Tag Git :
- Version de prépublication beta :
YYYY.M.D-beta.N- Tag Git :
vYYYY.M.D-beta.N
- Tag Git :
- Ne remplissez pas le mois ou le jour avec des zéros
latestsignifie la version npm stable promue actuellebetasignifie la cible d’installation beta actuelle- Les publications stables et correctives stables publient vers npm
betapar défaut ; les opérateurs de publication peuvent cibler explicitementlatest, ou promouvoir plus tard une build beta validée - Chaque publication OpenClaw livre ensemble le package npm et l’application macOS
Cadence de publication
- Les publications passent d’abord par beta
- Stable ne suit qu’après validation de la dernière beta
- La procédure détaillée de publication, les approbations, les identifiants et les notes de récupération sont réservées aux mainteneurs
Pré-vérification de publication
- Exécutez
pnpm build && pnpm ui:buildavantpnpm release:checkafin que les artefacts de publication attendusdist/*et le bundle Control UI existent pour l’étape de validation du pack - Exécutez
pnpm release:checkavant chaque publication taguée - La pré-vérification npm de la branche main exécute aussi
OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cacheavant l’empaquetage du tarball, en utilisant les secrets de workflowOPENAI_API_KEYetANTHROPIC_API_KEY - Exécutez
RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts(ou le tag beta/correctif correspondant) avant approbation - Après publication npm, exécutez
node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D(ou la version beta/corrective correspondante) pour vérifier le chemin d’installation depuis le registre publié dans un préfixe temporaire frais - L’automatisation de publication des mainteneurs utilise maintenant preflight-then-promote :
- la vraie publication npm doit réussir avec un
preflight_run_idnpm réussi - les publications npm stables ciblent par défaut
beta - une publication npm stable peut cibler explicitement
latestvia une entrée de workflow - la promotion npm stable de
betaverslatestreste disponible comme mode manuel explicite sur le workflow de confianceOpenClaw NPM Release - ce mode de promotion nécessite toujours un
NPM_TOKENvalide dans l’environnementnpm-releasecar la gestion desdist-tagnpm est séparée de la publication de confiance - la publication publique
macOS Releaseest uniquement une validation - la vraie publication mac privée doit réussir avec un
preflight_run_idetvalidate_run_idmac privés réussis - les vrais chemins de publication promeuvent des artefacts préparés au lieu de les reconstruire à nouveau
- la vraie publication npm doit réussir avec un
- Pour les publications correctives stables comme
YYYY.M.D-N, le vérificateur post-publication vérifie aussi le même chemin de mise à niveau en préfixe temporaire deYYYY.M.DversYYYY.M.D-Nafin que les corrections de publication ne puissent pas silencieusement laisser d’anciennes installations globales sur la charge utile stable de base - La pré-vérification de publication npm échoue de manière fermée sauf si le tarball inclut à la fois
dist/control-ui/index.htmlet une charge utile non videdist/control-ui/assets/afin d’éviter d’expédier de nouveau un tableau de bord navigateur vide - Si le travail de publication a touché la planification CI, les manifestes de timing d’extension, ou les matrices de test rapides, régénérez et examinez les sorties de matrice de workflow
checks-fast-extensionsdétenues par le planificateur depuis.github/workflows/ci.ymlavant approbation afin que les notes de publication ne décrivent pas une disposition CI obsolète - L’état de préparation de la publication stable macOS inclut aussi les surfaces de mise à jour :
- la publication GitHub doit finir avec le
.zip,.dmg, et.dSYM.zipempaquetés appcast.xmlsurmaindoit pointer vers le nouveau zip stable après publication- l’application empaquetée doit conserver un bundle id non debug, une URL de flux Sparkle non vide
et un
CFBundleVersionsupérieur ou égal au plancher canonique de build Sparkle pour cette version de publication
- la publication GitHub doit finir avec le
Entrées du workflow NPM
OpenClaw NPM Release accepte ces entrées contrôlées par l’opérateur :
tag: tag de publication requis commev2026.4.2,v2026.4.2-1, ouv2026.4.2-beta.1preflight_only:truepour validation/build/package uniquement,falsepour le vrai chemin de publicationpreflight_run_id: requis sur le vrai chemin de publication afin que le workflow réutilise le tarball préparé à partir de l’exécution preflight réussienpm_dist_tag: tag npm cible pour le chemin de publication ; vaut par défautbetapromote_beta_to_latest:truepour ignorer la publication et déplacer une build stablebetadéjà publiée verslatest
- Les tags stables et correctifs peuvent publier vers
betaoulatest - Les tags de prépublication beta ne peuvent publier que vers
beta - Le vrai chemin de publication doit utiliser le même
npm_dist_tagque celui utilisé pendant la pré-vérification ; le workflow vérifie ces métadonnées avant de poursuivre la publication - Le mode promotion doit utiliser un tag stable ou correctif,
preflight_only=false, unpreflight_run_idvide, etnpm_dist_tag=beta - Le mode promotion nécessite aussi un
NPM_TOKENvalide dans l’environnementnpm-releasecarnpm dist-tag addnécessite toujours une authentification npm classique
Séquence de publication npm stable
Lors de la découpe d’une publication npm stable :- Exécutez
OpenClaw NPM Releaseavecpreflight_only=true - Choisissez
npm_dist_tag=betapour le flux normal beta-first, oulatestseulement lorsque vous voulez délibérément une publication stable directe - Enregistrez le
preflight_run_idréussi - Exécutez de nouveau
OpenClaw NPM Releaseavecpreflight_only=false, le mêmetag, le mêmenpm_dist_tag, et lepreflight_run_idenregistré - Si la publication a atterri sur
beta, exécutez plus tardOpenClaw NPM Releaseavec le mêmetagstable,promote_beta_to_latest=true,preflight_only=false,preflight_run_idvide, etnpm_dist_tag=betalorsque vous voulez déplacer cette build publiée verslatest
npm-release et un
NPM_TOKEN valide dans cet environnement.
Cela garde documentés et visibles pour l’opérateur à la fois le chemin de publication directe et le chemin beta-first avec promotion.
Références publiques
.github/workflows/openclaw-npm-release.ymlscripts/openclaw-npm-release-check.tsscripts/package-mac-dist.shscripts/make_appcast.sh
openclaw/maintainers/release/README.md
pour le véritable runbook.