Releasebeleid

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• stable: getagde releases die standaard naar npm beta publiceren, of naar npm latest wanneer dit expliciet wordt gevraagd
• beta: prerelease-tags die naar npm beta publiceren
• dev: de bewegende kop van main

​

Versienaamgeving

• Stable-releaseversie: YYYY.M.D
  • Git-tag: vYYYY.M.D
• Stable-correctiereleaseversie: YYYY.M.D-N
  • Git-tag: vYYYY.M.D-N
• Beta-prereleaseversie: YYYY.M.D-beta.N
  • Git-tag: vYYYY.M.D-beta.N
• Gebruik geen voorloopnullen voor maand of dag
• latest betekent de huidige gepromote stable npm-release
• beta betekent het huidige beta-installatiedoel
• Stable- en stable-correctiereleases publiceren standaard naar npm beta; release-operators kunnen expliciet latest kiezen, of later een gecontroleerde beta-build promoveren
• Elke stable OpenClaw-release levert het npm-pakket en de macOS-app samen; beta-releases valideren en publiceren normaal gesproken eerst het npm-/pakketpad, waarbij bouwen/ondertekenen/notariëren van de Mac-app voor stable wordt gereserveerd, tenzij expliciet gevraagd

​

Releasetempo

• Releases gaan beta-first
• Stable volgt pas nadat de nieuwste beta is gevalideerd
• Maintainers maken releases normaal gesproken vanaf een release/YYYY.M.D-branch die is gemaakt vanaf de huidige main, zodat releasevalidatie en fixes nieuwe ontwikkeling op main niet blokkeren
• Als een beta-tag is gepusht of gepubliceerd en een fix nodig heeft, maken maintainers de volgende -beta.N-tag in plaats van de oude beta-tag te verwijderen of opnieuw te maken
• Gedetailleerde releaseprocedure, goedkeuringen, inloggegevens en herstelnotities zijn alleen voor maintainers

​

Checklist voor release-operator

1. Begin vanaf de huidige main: haal de nieuwste wijzigingen op, bevestig dat de doelcommit is gepusht, en bevestig dat de huidige main-CI groen genoeg is om er een branch van te maken.
2. Herschrijf de bovenste CHANGELOG.md-sectie op basis van echte commitgeschiedenis met /changelog, houd vermeldingen gebruikersgericht, commit dit, push dit, en rebase/pull nog een keer voordat je brancht.
3. Controleer releasecompatibiliteitsrecords in src/plugins/compat/registry.ts en src/commands/doctor/shared/deprecation-compat.ts. Verwijder verlopen compatibiliteit alleen wanneer het upgradepad gedekt blijft, of leg vast waarom deze bewust wordt behouden.
4. Maak release/YYYY.M.D vanaf de huidige main; doe normaal releasewerk niet direct op main.
5. Verhoog elke vereiste versielocatie voor de bedoelde tag en voer daarna pnpm release:prep uit. Dit ververst Plugin-versies, Plugin-inventaris, configuratie- schema, gebundelde kanaalconfiguratiemetadata, configuratiedocs-baseline, Plugin SDK- exports en Plugin SDK API-baseline in de juiste volgorde. Commit eventuele gegenereerde drift voordat je tagt. Voer daarna de lokale deterministische preflight uit: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, en pnpm release:check.
6. Voer OpenClaw NPM Release uit met preflight_only=true. Voordat er een tag bestaat, is een volledige release-branch-SHA van 40 tekens toegestaan voor alleen-validatie preflight. Bewaar de succesvolle preflight_run_id.
7. Start alle prerelease-tests met Full Release Validation voor de release-branch, tag of volledige commit-SHA. Dit is het ene handmatige toegangspunt voor de vier grote release-testboxen: Vitest, Docker, QA Lab en Package.
8. Als validatie faalt, fix dit op de release-branch en voer het kleinste gefaalde bestand, de lane, workflow-job, pakketprofiel, provider of model-allowlist opnieuw uit die de fix bewijst. Voer de volledige paraplu alleen opnieuw uit wanneer het gewijzigde oppervlak eerder bewijs verouderd maakt.
9. Voor beta: tag vYYYY.M.D-beta.N, voer daarna OpenClaw Release Publish uit vanaf de overeenkomende release/YYYY.M.D-branch. Dit verifieert pnpm plugins:sync:check, dispatcht alle publiceerbare Plugin-pakketten parallel naar npm en dezelfde set naar ClawHub, en promoveert daarna het voorbereide OpenClaw npm-preflight- artifact met de overeenkomende dist-tag zodra publiceren van Plugin npm slaagt. Nadat het OpenClaw npm publish-child is geslaagd, maakt of werkt het de overeenkomende GitHub-release-/prereleasepagina bij vanuit de volledige overeenkomende CHANGELOG.md-sectie. Stable-releases die naar npm latest zijn gepubliceerd, worden de nieuwste GitHub-release; stable-maintenance-releases die op npm beta blijven, worden gemaakt met GitHub latest=false. ClawHub-publicatie kan nog actief zijn terwijl OpenClaw npm publiceert, maar de release-publish-workflow print de child-run-ID’s direct. Standaard wacht deze niet op ClawHub na dispatch, zodat beschikbaarheid van OpenClaw npm niet wordt geblokkeerd door tragere ClawHub-goedkeuringen of registerwerk; stel wait_for_clawhub=true in wanneer ClawHub workflowvoltooiing moet blokkeren. Het ClawHub-pad probeert tijdelijke installatiefouten van CLI-afhankelijkheden opnieuw, publiceert plugins die de preview doorstaan, zelfs wanneer één preview-cel hapert, en eindigt met registerverificatie voor elke verwachte Plugin-versie zodat gedeeltelijke publicaties zichtbaar en opnieuw probeerbaar blijven. Voer na publicatie pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> uit om de GitHub-prerelease, npm beta-dist-tags, npm-integriteit, gepubliceerd installatiepad, exacte ClawHub-versies, ClawHub-artifacts en child- workflowconclusies vanuit één opdracht te verifiëren. Voeg --rerun-failed-clawhub toe wanneer de ClawHub-sidecar alleen in opnieuw probeerbare jobs faalde en ter plekke opnieuw moet worden uitgevoerd. Voer daarna de post-publish-pakketacceptatie uit tegen het gepubliceerde openclaw@YYYY.M.D-beta.N- of openclaw@beta-pakket. Als een gepushte of gepubliceerde prerelease een fix nodig heeft, maak dan het volgende overeenkomende prerelease-nummer; verwijder of herschrijf de oude prerelease niet.
10. Voor stable: ga alleen verder nadat de gecontroleerde beta of release candidate het vereiste validatiebewijs heeft. Stable npm-publicatie loopt ook via OpenClaw Release Publish, waarbij het succesvolle preflight-artifact via preflight_run_id wordt hergebruikt; gereedheid voor stable macOS-release vereist ook de verpakte .zip, .dmg, .dSYM.zip en bijgewerkte appcast.xml op main. De private macOS-publish-workflow publiceert de ondertekende appcast automatisch naar publieke main nadat release-assets zijn geverifieerd; als branchbescherming de directe push blokkeert, opent of werkt deze een appcast-PR bij.
11. Voer na publicatie de npm post-publish-verifier uit, optioneel zelfstandige gepubliceerde-npm Telegram E2E wanneer je post-publish kanaalbewijs nodig hebt, dist-tag-promotie wanneer nodig, verifieer de gegenereerde GitHub-releasepagina, en voer de release-aankondigingsstappen uit.

​

Release-preflight

• Voer pnpm check:test-types uit vóór release-preflight, zodat test-TypeScript gedekt blijft buiten de snellere lokale pnpm check-gate
• Voer pnpm check:architecture uit vóór release-preflight, zodat de bredere importcyclus- en architectuurgrenscontroles groen zijn buiten de snellere lokale gate
• Voer pnpm build && pnpm ui:build uit vóór pnpm release:check, zodat de verwachte dist/*-releaseartefacten en de Control UI-bundel bestaan voor de pakketvalidatiestap
• Voer pnpm release:prep uit na de root-versieverhoging en vóór het taggen. Het voert elke deterministische releasegenerator uit die vaak afwijkt na een versie-/config-/API-wijziging: Plugin-versies, Plugin-inventaris, basisconfiguratie- schema, gebundelde kanaalconfiguratie-metadata, basislijn voor configuratiedocs, Plugin SDK-exports en Plugin SDK-API-basislijn. pnpm release:check voert die bewakers opnieuw uit in checkmodus en rapporteert elke gegenereerde afwijkingsfout die het vindt in één doorgang voordat pakketreleasecontroles worden uitgevoerd.
• Voer de handmatige Full Release Validation-workflow uit vóór releasegoedkeuring om alle pre-release testboxen vanuit één toegangspunt te starten. Deze accepteert een branch, tag of volledige commit-SHA, dispatcht handmatig CI en dispatcht OpenClaw Release Checks voor installatiesmoke, pakketacceptatie, cross-OS pakketcontroles, QA Lab-pariteit, Matrix- en Telegram-lanes. Stabiele/standaardruns houden uitputtende live/E2E- en Docker-releasepad-soak achter run_release_soak=true; release_profile=full dwingt soak af. Met release_profile=full en rerun_group=all voert het ook pakket-Telegram E2E uit tegen het release-package-under-test-artefact uit releasecontroles. Geef release_package_spec op na het publiceren van een bèta om het verscheepte npm-pakket opnieuw te gebruiken voor releasecontroles, Package Acceptance en pakket-Telegram E2E zonder de release-tarball opnieuw te bouwen. Geef npm_telegram_package_spec alleen op wanneer Telegram een ander gepubliceerd pakket moet gebruiken dan de rest van releasevalidatie. Geef package_acceptance_package_spec op wanneer Package Acceptance een ander gepubliceerd pakket moet gebruiken dan de releasepakket-specificatie. Geef evidence_package_spec op wanneer het private bewijsrapport moet aantonen dat de validatie overeenkomt met een gepubliceerd npm-pakket zonder Telegram E2E af te dwingen. Voorbeeld: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• Voer de handmatige Package Acceptance-workflow uit wanneer je side-channel-bewijs wilt voor een pakketkandidaat terwijl releasewerk doorgaat. Gebruik source=npm voor openclaw@beta, openclaw@latest of een exacte releaseversie; source=ref om een vertrouwde package_ref-branch/tag/SHA te packen met de huidige workflow_ref-harness; source=url voor een HTTPS-tarball met een vereiste SHA-256; of source=artifact voor een tarball die door een andere GitHub Actions-run is geüpload. De workflow herleidt de kandidaat tot package-under-test, hergebruikt de Docker E2E-releasescheduler tegen die tarball en kan Telegram QA tegen dezelfde tarball uitvoeren met telegram_mode=mock-openai of telegram_mode=live-frontier. Wanneer de geselecteerde Docker-lanes published-upgrade-survivor bevatten, is het pakket- artefact de kandidaat en selecteert published_upgrade_survivor_baseline de gepubliceerde basislijn. update-restart-auth gebruikt het kandidaatpakket als zowel de geïnstalleerde CLI als het package-under-test, zodat het het managed restart-pad van het updatecommando van de kandidaat oefent. Voorbeeld: gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai Gangbare profielen:
  • smoke: install/channel/agent-, Gateway-netwerk- en configuratieherlaadlanes
  • package: artefact-native package/update/restart/Plugin-lanes zonder OpenWebUI of live ClawHub
  • product: package-profiel plus MCP-kanalen, Cron-/subagent-opruiming, OpenAI-webzoekopdracht en OpenWebUI
  • full: Docker-releasepad-chunks met OpenWebUI
  • custom: exacte docker_lanes-selectie voor een gerichte rerun
• Voer de handmatige CI-workflow direct uit wanneer je alleen volledige normale CI- dekking nodig hebt voor de releasekandidaat. Handmatige CI-dispatches omzeilen gewijzigde scoping en forceren de Linux Node-shards, gebundelde-Plugin-shards, kanaal- contracten, Node 22-compatibiliteit, check, check-additional, build-smoke, docs-controles, Python Skills, Windows, macOS, Android en Control UI i18n- lanes. Voorbeeld: gh workflow run ci.yml --ref release/YYYY.M.D
• Voer pnpm qa:otel:smoke uit bij het valideren van releasetelemetrie. Het oefent QA-lab via een lokale OTLP/HTTP-ontvanger en verifieert de geëxporteerde trace- span-namen, begrensde attributen en redactie van inhoud/identifiers zonder Opik, Langfuse of een andere externe collector te vereisen.
• Voer pnpm release:check uit vóór elke getagde release
• Voer OpenClaw Release Publish uit voor de muterende publicatiereeks nadat de tag bestaat. Dispatch deze vanuit release/YYYY.M.D (of main wanneer je een vanaf main bereikbare tag publiceert), geef de releasetag en succesvolle OpenClaw npm preflight_run_id door en behoud de standaard Plugin-publicatiescope all-publishable, tenzij je bewust een gerichte reparatie uitvoert. De workflow serialiseert Plugin-npm-publicatie, Plugin-ClawHub-publicatie en OpenClaw npm-publicatie, zodat het corepakket niet vóór de geëxternaliseerde plugins wordt gepubliceerd.
• Releasecontroles draaien nu in een aparte handmatige workflow: OpenClaw Release Checks
• OpenClaw Release Checks voert ook de QA Lab mock-pariteitslane plus het snelle live Matrix-profiel en de Telegram QA-lane uit vóór releasegoedkeuring. De live lanes gebruiken de qa-live-shared-omgeving; Telegram gebruikt ook Convex CI- credentialleases. Voer de handmatige QA-Lab - All Lanes-workflow uit met matrix_profile=all en matrix_shards=true wanneer je volledige Matrix- transport-, media- en E2EE-inventaris parallel wilt.
• Cross-OS installatie- en upgrade-runtimevalidatie maakt deel uit van publieke OpenClaw Release Checks en Full Release Validation, die de herbruikbare workflow .github/workflows/openclaw-cross-os-release-checks-reusable.yml direct aanroepen
• Deze splitsing is opzettelijk: houd het echte npm-releasepad kort, deterministisch en artefactgericht, terwijl langzamere livecontroles in hun eigen lane blijven zodat ze publiceren niet ophouden of blokkeren
• Releasecontroles met geheimen moeten worden gedispatcht via Full Release Validation of vanuit de main/release-workflowref, zodat workflowlogica en geheimen gecontroleerd blijven
• OpenClaw Release Checks accepteert een branch, tag of volledige commit-SHA zolang de herleide commit bereikbaar is vanaf een OpenClaw-branch of releasetag
• OpenClaw NPM Release validation-only preflight accepteert ook de huidige volledige 40-tekens workflow-branch-commit-SHA zonder een gepushte tag te vereisen
• Dat SHA-pad is alleen voor validatie en kan niet worden gepromoveerd naar een echte publicatie
• In SHA-modus synthetiseert de workflow v<package.json version> alleen voor de pakketmetadata-controle; echte publicatie vereist nog steeds een echte releasetag
• Beide workflows houden het echte publicatie- en promotiepad op GitHub-gehoste runners, terwijl het niet-muterende validatiepad de grotere Blacksmith Linux-runners kan gebruiken
• Die workflow voert OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache uit met zowel OPENAI_API_KEY als ANTHROPIC_API_KEY workflowsecrets
• npm-releasepreflight wacht niet langer op de aparte releasecontroles-lane
• Voer vóór het lokaal taggen van een releasekandidaat RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check uit. De helper voert de snelle releasebewakingsregels, Plugin npm-/ClawHub-releasecontroles, build, UI-build en release:openclaw:npm:check uit in de volgorde die veelvoorkomende goedkeuringsblokkerende fouten opvangt voordat de GitHub-publicatieworkflow start.
• Voer RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (of de overeenkomende bèta-/correctietag) uit vóór goedkeuring
• Voer na npm-publicatie node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (of de overeenkomende bèta-/correctieversie) uit om het gepubliceerde registry- installatiepad te verifiëren in een verse tijdelijke prefix
• Voer na een bèta-publicatie OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live uit om installed-package-onboarding, Telegram-configuratie en echte Telegram E2E te verifiëren tegen het gepubliceerde npm-pakket met de gedeelde geleasede Telegram- credentialpool. Lokale eenmalige maintainer-runs mogen de Convex-vars weglaten en de drie OPENCLAW_QA_TELEGRAM_*-env-credentials direct doorgeven.
• Gebruik pnpm release:beta-smoke -- --beta betaN om de volledige post-publish bèta-smoke vanaf een maintainer-machine uit te voeren. De helper voert Parallels npm update-/fresh-targetvalidatie uit, dispatcht NPM Telegram Beta E2E, pollt de exacte workflowrun, downloadt het artefact en print het Telegram-rapport.
• Maintainers kunnen dezelfde post-publish-controle uitvoeren vanuit GitHub Actions via de handmatige NPM Telegram Beta E2E-workflow. Deze is bewust alleen handmatig en draait niet bij elke merge.
• Maintainer-releaseautomatisering gebruikt nu preflight-dan-promote:
  • echte npm-publicatie moet slagen met een succesvolle npm preflight_run_id
  • de echte npm-publicatie moet worden gedispatcht vanaf dezelfde main- of release/YYYY.M.D-branch als de succesvolle preflight-run
  • stabiele npm-releases gebruiken standaard beta
  • stabiele npm-publicatie kan expliciet op latest mikken via workflowinput
  • tokengebaseerde npm dist-tag-mutatie leeft nu in openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml voor beveiliging, omdat npm dist-tag add nog steeds NPM_TOKEN nodig heeft terwijl de publieke repo OIDC-only publicatie behoudt
  • publieke macOS Release is alleen validatie; wanneer een tag alleen op een releasebranch bestaat maar de workflow vanuit main wordt gedispatcht, stel dan public_release_branch=release/YYYY.M.D in
  • echte private mac-publicatie moet slagen met succesvolle private mac preflight_run_id en validate_run_id
  • de echte publicatiepaden promoten voorbereide artefacten in plaats van ze opnieuw te bouwen
• Voor stabiele correctiereleases zoals YYYY.M.D-N controleert de post-publish-verifier ook hetzelfde temp-prefix-upgradepad van YYYY.M.D naar YYYY.M.D-N, zodat releasecorrecties oudere globale installaties niet stilzwijgend op de basis-stabiele payload kunnen laten staan
• npm-releasepreflight faalt gesloten tenzij de tarball zowel dist/control-ui/index.html als een niet-lege dist/control-ui/assets/-payload bevat, zodat we niet opnieuw een leeg browserdashboard verschepen
• Post-publish-verificatie controleert ook of gepubliceerde Plugin-entrypoints en pakketmetadata aanwezig zijn in de geïnstalleerde registry-layout. Een release die ontbrekende Plugin-runtimepayloads verscheept, faalt de postpublish-verifier en kan niet worden gepromoveerd naar latest.
• pnpm test:install:smoke dwingt ook het npm-pack unpackedSize-budget af op de kandidaat-update-tarball, zodat installer-e2e onbedoelde pakketgroei opvangt vóór het releasepublicatiepad
• Als het releasewerk CI-planning, extensietimingmanifests of extensietestmatrices raakte, regenereer en review dan de planner-owned plugin-prerelease-extension-shard-matrixoutputs uit .github/workflows/plugin-prerelease.yml vóór goedkeuring, zodat releasenotities geen verouderde CI-layout beschrijven
• Stabiele macOS-releasegereedheid omvat ook de updater-oppervlakken:
  • de GitHub-release moet eindigen met de verpakte .zip, .dmg en .dSYM.zip
  • appcast.xml op main moet na publicatie naar de nieuwe stabiele zip verwijzen; de private macOS-publicatieworkflow commit deze automatisch, of opent een appcast- PR wanneer direct pushen is geblokkeerd
  • de verpakte app moet een niet-debug bundle-id, een niet-lege Sparkle-feed- URL en een CFBundleVersion op of boven de canonieke Sparkle-buildvloer voor die releaseversie behouden

​

Release-testboxes

pnpm ci:full-release --sha <full-sha>

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N

• minimum: snelste release-kritieke OpenAI/core live- en Docker-pad
• stable: minimum plus stable provider/backend-dekking voor releasegoedkeuring
• full: stable plus brede advisory provider/media-dekking

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \
  -f npm_telegram_provider_mode=mock-openai

​

Vitest

• Full Release Validation-samenvatting met de gedispatchte CI-run-URL
• CI-run groen op de exacte doel-SHA
• gefaalde of trage shardnamen uit de CI-jobs bij onderzoek naar regressies
• Vitest-timingartefacten zoals .artifacts/vitest-shard-timings.json wanneer een run prestatieanalyse nodig heeft

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

​

Docker

• volledige install smoke met de trage Bun global install smoke ingeschakeld
• voorbereiding/hergebruik van de root-Dockerfile-smoke-image per doel-SHA, met QR-, root/Gateway- en installer/Bun-smoke-jobs als afzonderlijke install-smoke-shards
• repository-E2E-lanes
• releasepad-Docker-chunks: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g en plugins-runtime-install-h
• OpenWebUI-dekking binnen de chunk plugins-runtime-services wanneer gevraagd
• gesplitste install/uninstall-lanes voor gebundelde Plugins bundled-plugin-install-uninstall-0 tot en met bundled-plugin-install-uninstall-23
• live/E2E-provider-suites en Docker-live-modeldekking wanneer releasechecks live suites bevatten

​

QA Lab

• mock-parity-lane die de OpenAI-candidate-lane vergelijkt met de Opus 4.6 baseline via het agentic parity pack
• snel live Matrix-QA-profiel met de qa-live-shared-omgeving
• live Telegram-QA-lane met Convex CI-credentialleases
• pnpm qa:otel:smoke wanneer releasetelemetrie expliciet lokaal bewijs nodig heeft

​

Package

• source=npm: openclaw@beta, openclaw@latest of een exacte OpenClaw-releaseversie
• source=ref: pack een vertrouwde package_ref-branch, tag of volledige commit-SHA met de geselecteerde workflow_ref-harness
• source=url: download een HTTPS .tgz met vereiste package_sha256
• source=artifact: hergebruik een .tgz die door een andere GitHub Actions-run is geüpload

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

• smoke: snelle pakketinstallatie-/kanaal-/agent-, Gateway-netwerk- en config- herlaadlanes
• package: installatie-/update-/herstart-/Plugin-pakketcontracten plus live ClawHub- Skills-installatiebewijs; dit is de standaard voor releasecontroles
• product: package plus MCP-kanalen, cron/subagent-opschoning, OpenAI-web zoeken en OpenWebUI
• full: Docker-releasepad-chunks met OpenWebUI
• custom: exacte docker_lanes-lijst voor gerichte herhalingen

​

Releasepublicatieautomatisering

1. Check de releasetag uit en los de commit-SHA ervan op.
2. Verifieer dat de tag bereikbaar is vanaf main of release/*.
3. Voer pnpm plugins:sync:check uit.
4. Dispatch Plugin NPM Release met publish_scope=all-publishable en ref=<release-sha>.
5. Dispatch Plugin ClawHub Release met dezelfde scope en SHA.
6. Dispatch OpenClaw NPM Release met de releasetag, npm-dist-tag en opgeslagen preflight_run_id.

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest

​

NPM-workflowinvoer

• tag: vereiste releasetag zoals v2026.4.2, v2026.4.2-1 of v2026.4.2-beta.1; wanneer preflight_only=true, mag dit ook de huidige volledige 40-tekens workflowbranch-commit-SHA zijn voor alleen-validatie-preflight
• preflight_only: true voor alleen validatie/build/pakket, false voor het echte publicatiepad
• preflight_run_id: vereist op het echte publicatiepad, zodat de workflow de voorbereide tarball uit de succesvolle preflight-run hergebruikt
• npm_dist_tag: npm-doeltag voor het publicatiepad; standaard beta

• tag: vereiste releasetag; moet al bestaan
• preflight_run_id: succesvolle OpenClaw NPM Release-preflight-run-id; vereist wanneer publish_openclaw_npm=true
• npm_dist_tag: npm-doeltag voor het OpenClaw-pakket
• plugin_publish_scope: standaard all-publishable; gebruik selected alleen voor gericht herstelwerk
• plugins: kommagescheiden @openclaw/*-pakketnamen wanneer plugin_publish_scope=selected
• publish_openclaw_npm: standaard true; stel alleen false in wanneer de workflow wordt gebruikt als alleen-Plugin-herstelorkestrator
• wait_for_clawhub: standaard false, zodat npm-beschikbaarheid niet wordt geblokkeerd door de ClawHub-sidecar; stel alleen true in wanneer workflowvoltooiing ook ClawHub-voltooiing moet omvatten

• ref: branch, tag of volledige commit-SHA om te valideren. Controles met secrets vereisen dat de opgeloste commit bereikbaar is vanaf een OpenClaw-branch of releasetag.
• run_release_soak: kies voor uitputtende live/E2E-, Docker-releasepad- en all-since upgrade-survivor-soak op stabiele/standaardreleasecontroles. Dit wordt afgedwongen door release_profile=full.

• Stabiele en correctietags mogen naar beta of latest publiceren
• Beta-prereleasetags mogen alleen naar beta publiceren
• Voor OpenClaw NPM Release is volledige commit-SHA-invoer alleen toegestaan wanneer preflight_only=true
• OpenClaw Release Checks en Full Release Validation zijn altijd alleen-validatie
• Het echte publicatiepad moet dezelfde npm_dist_tag gebruiken als tijdens preflight; de workflow verifieert die metadata voordat de publicatie doorgaat

​

Stabiele npm-releasereeks

1. Voer OpenClaw NPM Release uit met preflight_only=true
   • Voordat een tag bestaat, mag u de huidige volledige workflowbranch-commit- SHA gebruiken voor een alleen-validatie-droogrun van de preflight-workflow
2. Kies npm_dist_tag=beta voor de normale beta-first-flow, of alleen latest wanneer u bewust rechtstreeks stabiel wilt publiceren
3. Voer Full Release Validation uit op de releasebranch, releasetag of volledige commit-SHA wanneer u normale CI plus live promptcache, Docker, QA Lab, Matrix en Telegram-dekking vanuit één handmatige workflow wilt
4. Als u bewust alleen de deterministische normale testgraaf nodig hebt, voert u in plaats daarvan de handmatige CI-workflow uit op de release-ref
5. Sla de succesvolle preflight_run_id op
6. Voer OpenClaw Release Publish uit met dezelfde tag, dezelfde npm_dist_tag, en de opgeslagen preflight_run_id; deze publiceert geëxternaliseerde Plugins naar npm en ClawHub voordat het OpenClaw-npm-pakket wordt gepromoveerd
7. Als de release op beta is geland, gebruikt u de private openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml- workflow om die stabiele versie van beta naar latest te promoveren
8. Als de release bewust rechtstreeks naar latest is gepubliceerd en beta onmiddellijk dezelfde stabiele build moet volgen, gebruikt u dezelfde private workflow om beide dist-tags naar de stabiele versie te laten wijzen, of laat u de geplande zelfherstellende synchronisatie beta later verplaatsen

​

Publieke verwijzingen

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

​

Gerelateerd

• Releasekanalen