Política de lanzamientos

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.

• estable: lanzamientos etiquetados que se publican en npm beta de forma predeterminada, o en npm latest cuando se solicita explícitamente
• beta: etiquetas de prelanzamiento que se publican en npm beta
• desarrollo: la cabeza móvil de main

​

Nomenclatura de versiones

• Versión de lanzamiento estable: YYYY.M.D
  • Etiqueta Git: vYYYY.M.D
• Versión de lanzamiento de corrección estable: YYYY.M.D-N
  • Etiqueta Git: vYYYY.M.D-N
• Versión de prelanzamiento beta: YYYY.M.D-beta.N
  • Etiqueta Git: vYYYY.M.D-beta.N
• No rellenes con ceros el mes ni el día
• latest significa el lanzamiento estable actual promovido en npm
• beta significa el destino actual de instalación beta
• Los lanzamientos estables y de corrección estable se publican en npm beta de forma predeterminada; los operadores de lanzamiento pueden apuntar explícitamente a latest, o promover más tarde una compilación beta revisada
• Cada lanzamiento estable de OpenClaw incluye conjuntamente el paquete npm y la app para macOS; los lanzamientos beta normalmente validan y publican primero la ruta npm/paquete, con la compilación/firma/notarización de la app para Mac reservada para estable salvo que se solicite explícitamente

​

Cadencia de lanzamientos

• Los lanzamientos avanzan primero por beta
• Estable llega solo después de validar la beta más reciente
• Los mantenedores normalmente cortan lanzamientos desde una rama release/YYYY.M.D creada desde el main actual, de modo que la validación y las correcciones del lanzamiento no bloqueen el nuevo desarrollo en main
• Si una etiqueta beta se ha enviado o publicado y necesita una corrección, los mantenedores cortan la siguiente etiqueta -beta.N en lugar de eliminar o recrear la etiqueta beta anterior
• El procedimiento detallado de lanzamiento, las aprobaciones, las credenciales y las notas de recuperación son solo para mantenedores

​

Lista de comprobación del operador de lanzamiento

1. Empieza desde el main actual: trae lo más reciente, confirma que el commit objetivo se ha enviado, y confirma que la CI actual de main está lo bastante verde como para ramificar desde ahí.
2. Reescribe la sección superior de CHANGELOG.md a partir del historial real de commits con /changelog, mantén las entradas orientadas al usuario, haz commit, súbelo, y haz rebase/pull una vez más antes de crear la rama.
3. Revisa los registros de compatibilidad de lanzamiento en src/plugins/compat/registry.ts y src/commands/doctor/shared/deprecation-compat.ts. Elimina la compatibilidad vencida solo cuando la ruta de actualización siga cubierta, o registra por qué se mantiene intencionalmente.
4. Crea release/YYYY.M.D desde el main actual; no hagas el trabajo normal de lanzamiento directamente en main.
5. Incrementa cada ubicación de versión requerida para la etiqueta prevista, luego ejecuta pnpm release:prep. Actualiza versiones de plugins, inventario de plugins, esquema de configuración, metadatos de configuración de canales incluidos, baseline de documentación de configuración, exportaciones del SDK de plugins y baseline de API del SDK de plugins en el orden correcto. Haz commit de cualquier deriva generada antes de etiquetar. Luego ejecuta el preflight determinista local: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, y pnpm release:check.
6. Ejecuta OpenClaw NPM Release con preflight_only=true. Antes de que exista una etiqueta, se permite un SHA completo de 40 caracteres de la rama de lanzamiento para el preflight solo de validación. Guarda el preflight_run_id exitoso.
7. Inicia todas las pruebas previas al lanzamiento con Full Release Validation para la rama de lanzamiento, etiqueta o SHA completo del commit. Este es el único punto de entrada manual para los cuatro grandes cuadros de pruebas de lanzamiento: Vitest, Docker, QA Lab y Package.
8. Si la validación falla, corrige en la rama de lanzamiento y vuelve a ejecutar el archivo, carril, job de workflow, perfil de paquete, proveedor o allowlist de modelos más pequeño que pruebe la corrección. Vuelve a ejecutar el paraguas completo solo cuando la superficie modificada vuelva obsoleta la evidencia previa.
9. Para beta, etiqueta vYYYY.M.D-beta.N, luego ejecuta OpenClaw Release Publish desde la rama release/YYYY.M.D correspondiente. Verifica pnpm plugins:sync:check, despacha todos los paquetes de plugins publicables a npm y el mismo conjunto a ClawHub en paralelo, y luego promueve el artefacto de preflight npm preparado de OpenClaw con el dist-tag correspondiente en cuanto la publicación npm de plugins tiene éxito. Después de que el hijo de publicación npm de OpenClaw tiene éxito, crea o actualiza la página de lanzamiento/prelanzamiento de GitHub correspondiente desde la sección completa correspondiente de CHANGELOG.md. Los lanzamientos estables publicados en npm latest se convierten en el último lanzamiento de GitHub; los lanzamientos de mantenimiento estable mantenidos en npm beta se crean con GitHub latest=false. La publicación en ClawHub todavía puede estar ejecutándose mientras OpenClaw se publica en npm, pero el workflow de publicación de lanzamiento imprime los ID de ejecución hijos de inmediato. De forma predeterminada, no espera a ClawHub después de despacharlo, por lo que la disponibilidad npm de OpenClaw no queda bloqueada por aprobaciones o trabajo de registro más lentos en ClawHub; establece wait_for_clawhub=true cuando ClawHub deba bloquear la finalización del workflow. La ruta de ClawHub reintenta fallos transitorios de instalación de dependencias de la CLI, publica plugins que pasan la vista previa incluso cuando una celda de vista previa falla intermitentemente, y termina con verificación de registro para cada versión de plugin esperada, de modo que las publicaciones parciales sigan siendo visibles y reintentables. Después de publicar, ejecuta pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> para verificar desde un solo comando el prelanzamiento de GitHub, los dist-tags npm beta, la integridad npm, la ruta de instalación publicada, las versiones exactas en ClawHub, los artefactos de ClawHub y las conclusiones de los workflows hijos. Añade --rerun-failed-clawhub cuando el sidecar de ClawHub haya fallado solo en jobs reintentables y deba volver a ejecutarse in situ. Luego ejecuta la aceptación de paquete posterior a la publicación contra el paquete publicado openclaw@YYYY.M.D-beta.N u openclaw@beta. Si un prelanzamiento enviado o publicado necesita una corrección, corta el siguiente número de prelanzamiento correspondiente; no elimines ni reescribas el prelanzamiento anterior.
10. Para estable, continúa solo después de que la beta revisada o la candidata de lanzamiento tenga la evidencia de validación requerida. La publicación npm estable también pasa por OpenClaw Release Publish, reutilizando el artefacto de preflight exitoso mediante preflight_run_id; la preparación del lanzamiento estable para macOS también requiere el .zip, .dmg, .dSYM.zip empaquetados y el appcast.xml actualizado en main. El workflow privado de publicación para macOS publica automáticamente el appcast firmado en el main público después de verificar los activos de lanzamiento; si la protección de rama bloquea el envío directo, abre o actualiza un PR de appcast.
11. Después de publicar, ejecuta el verificador npm posterior a la publicación, el E2E independiente opcional de Telegram con npm publicado cuando necesites prueba de canal posterior a la publicación, la promoción de dist-tag cuando sea necesaria, verifica la página de lanzamiento de GitHub generada, y ejecuta los pasos de anuncio del lanzamiento.

​

Preflight de lanzamiento

• Ejecuta pnpm check:test-types antes de la comprobación previa de la versión para que el TypeScript de pruebas quede cubierto fuera de la puerta local más rápida pnpm check
• Ejecuta pnpm check:architecture antes de la comprobación previa de la versión para que las comprobaciones más amplias de ciclos de importación y límites de arquitectura estén en verde fuera de la puerta local más rápida
• Ejecuta pnpm build && pnpm ui:build antes de pnpm release:check para que existan los artefactos de versión esperados dist/* y el paquete de Control UI para el paso de validación de empaquetado
• Ejecuta pnpm release:prep después del aumento de versión raíz y antes de etiquetar. Ejecuta todos los generadores deterministas de versión que suelen desviarse después de un cambio de versión/configuración/API: versiones de plugins, inventario de plugins, esquema de configuración base, metadatos de configuración de canales incluidos, línea base de documentación de configuración, exportaciones del SDK de plugins y línea base de API del SDK de plugins. pnpm release:check vuelve a ejecutar esas defensas en modo de comprobación y reporta todos los fallos de deriva generada que encuentra en una sola pasada antes de ejecutar las comprobaciones de publicación de paquetes.
• Ejecuta el workflow manual Full Release Validation antes de aprobar la versión para iniciar todos los entornos de prueba previos a la versión desde un único punto de entrada. Acepta una rama, una etiqueta o un SHA completo de commit, lanza manualmente CI y lanza OpenClaw Release Checks para install smoke, aceptación de paquetes, comprobaciones de paquetes entre sistemas operativos, paridad de QA Lab, Matrix y carriles de Telegram. Las ejecuciones estables/predeterminadas mantienen las pruebas exhaustivas live/E2E y la prueba prolongada de la ruta de versión de Docker detrás de run_release_soak=true; release_profile=full fuerza la prueba prolongada. Con release_profile=full y rerun_group=all, también ejecuta Telegram E2E de paquete contra el artefacto release-package-under-test de las comprobaciones de versión. Proporciona release_package_spec después de publicar una beta para reutilizar el paquete npm publicado en las comprobaciones de versión, Package Acceptance y Telegram E2E de paquete sin reconstruir el tarball de versión. Proporciona npm_telegram_package_spec solo cuando Telegram deba usar un paquete publicado distinto al del resto de la validación de versión. Proporciona package_acceptance_package_spec cuando Package Acceptance deba usar un paquete publicado distinto al spec del paquete de versión. Proporciona evidence_package_spec cuando el informe privado de evidencia deba probar que la validación coincide con un paquete npm publicado sin forzar Telegram E2E. Ejemplo: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• Ejecuta el workflow manual Package Acceptance cuando quieras una prueba por canal lateral para un candidato de paquete mientras continúa el trabajo de versión. Usa source=npm para openclaw@beta, openclaw@latest o una versión exacta de publicación; source=ref para empaquetar una rama/etiqueta/SHA confiable de package_ref con el arnés actual de workflow_ref; source=url para un tarball HTTPS con SHA-256 requerido; o source=artifact para un tarball subido por otra ejecución de GitHub Actions. El workflow resuelve el candidato a package-under-test, reutiliza el programador de versiones Docker E2E contra ese tarball y puede ejecutar QA de Telegram contra el mismo tarball con telegram_mode=mock-openai o telegram_mode=live-frontier. Cuando los carriles Docker seleccionados incluyen published-upgrade-survivor, el artefacto de paquete es el candidato y published_upgrade_survivor_baseline selecciona la línea base publicada. update-restart-auth usa el paquete candidato tanto como la CLI instalada como el package-under-test, por lo que ejercita la ruta de reinicio administrado del comando de actualización candidato. Ejemplo: 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 Perfiles comunes:
  • smoke: carriles de instalación/canal/agente, red de Gateway y recarga de configuración
  • package: carriles nativos de artefacto para paquete/actualización/reinicio/plugin sin OpenWebUI ni ClawHub live
  • product: perfil de paquete más canales MCP, limpieza de cron/subagente, búsqueda web de OpenAI y OpenWebUI
  • full: fragmentos de ruta de versión Docker con OpenWebUI
  • custom: selección exacta de docker_lanes para una reejecución enfocada
• Ejecuta directamente el workflow manual CI cuando solo necesites cobertura completa de CI normal para el candidato de versión. Los lanzamientos manuales de CI omiten el alcance por cambios y fuerzan los shards de Linux Node, shards de plugins incluidos, contratos de canal, compatibilidad con Node 22, check, check-additional, build smoke, comprobaciones de documentación, Skills de Python, Windows, macOS, Android y carriles de i18n de Control UI. Ejemplo: gh workflow run ci.yml --ref release/YYYY.M.D
• Ejecuta pnpm qa:otel:smoke al validar la telemetría de versión. Ejercita QA-lab mediante un receptor OTLP/HTTP local y verifica los nombres de span de traza exportados, atributos acotados y redacción de contenido/identificadores sin requerir Opik, Langfuse ni otro colector externo.
• Ejecuta pnpm release:check antes de cada versión etiquetada
• Ejecuta OpenClaw Release Publish para la secuencia mutante de publicación después de que exista la etiqueta. Lánzalo desde release/YYYY.M.D (o main al publicar una etiqueta alcanzable desde main), pasa la etiqueta de versión y el preflight_run_id exitoso de npm de OpenClaw, y conserva el alcance predeterminado de publicación de plugins all-publishable salvo que estés ejecutando deliberadamente una reparación enfocada. El workflow serializa la publicación npm de plugins, la publicación de plugins en ClawHub y la publicación npm de OpenClaw para que el paquete core no se publique antes que sus plugins externalizados.
• Las comprobaciones de versión ahora se ejecutan en un workflow manual separado: OpenClaw Release Checks
• OpenClaw Release Checks también ejecuta el carril de paridad simulada de QA Lab más el perfil rápido live de Matrix y el carril de QA de Telegram antes de aprobar la versión. Los carriles live usan el entorno qa-live-shared; Telegram también usa concesiones de credenciales de Convex CI. Ejecuta el workflow manual QA-Lab - All Lanes con matrix_profile=all y matrix_shards=true cuando quieras el inventario completo de transporte, medios y E2EE de Matrix en paralelo.
• La validación de instalación y actualización en tiempo de ejecución entre sistemas operativos forma parte de los workflows públicos OpenClaw Release Checks y Full Release Validation, que llaman directamente al workflow reutilizable .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Esta separación es intencional: mantener la ruta real de versión npm breve, determinista y enfocada en artefactos, mientras que las comprobaciones live más lentas permanecen en su propio carril para que no retrasen ni bloqueen la publicación
• Las comprobaciones de versión que contienen secretos deben lanzarse mediante Full Release Validation o desde la referencia de workflow main/release para que la lógica del workflow y los secretos permanezcan controlados
• OpenClaw Release Checks acepta una rama, una etiqueta o un SHA completo de commit siempre que el commit resuelto sea alcanzable desde una rama o etiqueta de versión de OpenClaw
• La comprobación previa solo de validación de OpenClaw NPM Release también acepta el SHA completo de 40 caracteres del commit actual de la rama del workflow sin requerir una etiqueta enviada
• Esa ruta SHA es solo de validación y no puede promocionarse a una publicación real
• En modo SHA, el workflow sintetiza v<package.json version> solo para la comprobación de metadatos del paquete; la publicación real sigue requiriendo una etiqueta de versión real
• Ambos workflows mantienen la ruta real de publicación y promoción en runners alojados en GitHub, mientras que la ruta de validación no mutante puede usar los runners Linux más grandes de Blacksmith
• Ese workflow ejecuta OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache usando los secretos de workflow OPENAI_API_KEY y ANTHROPIC_API_KEY
• La comprobación previa de versión npm ya no espera el carril separado de comprobaciones de versión
• Antes de etiquetar localmente un candidato de versión, ejecuta RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check. El helper ejecuta las defensas rápidas de versión, las comprobaciones de versión npm/ClawHub de plugins, build, build de UI y release:openclaw:npm:check en el orden que detecta errores comunes que bloquean aprobaciones antes de que comience el workflow de publicación de GitHub.
• Ejecuta RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (o la etiqueta beta/corrección correspondiente) antes de la aprobación
• Después de publicar en npm, ejecuta node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (o la versión beta/corrección correspondiente) para verificar la ruta de instalación del registro publicado en un prefijo temporal limpio
• Después de publicar una beta, ejecuta 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 para verificar el onboarding de paquete instalado, la configuración de Telegram y Telegram E2E real contra el paquete npm publicado usando el pool compartido de credenciales de Telegram concedidas. Las ejecuciones locales puntuales de maintainers pueden omitir las variables de Convex y pasar directamente las tres credenciales de entorno OPENCLAW_QA_TELEGRAM_*.
• Para ejecutar el smoke beta completo posterior a la publicación desde una máquina de maintainer, usa pnpm release:beta-smoke -- --beta betaN. El helper ejecuta la validación de actualización npm/fresh-target de Parallels, lanza NPM Telegram Beta E2E, sondea la ejecución exacta del workflow, descarga el artefacto e imprime el informe de Telegram.
• Los maintainers pueden ejecutar la misma comprobación posterior a la publicación desde GitHub Actions mediante el workflow manual NPM Telegram Beta E2E. Es intencionalmente solo manual y no se ejecuta en cada merge.
• La automatización de versiones de maintainers ahora usa comprobación previa y luego promoción:
  • la publicación npm real debe pasar un preflight_run_id npm exitoso
  • la publicación npm real debe lanzarse desde la misma rama main o release/YYYY.M.D que la ejecución exitosa de comprobación previa
  • las versiones npm estables predeterminan a beta
  • la publicación npm estable puede apuntar explícitamente a latest mediante input del workflow
  • la mutación de dist-tag de npm basada en token ahora vive en openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml por seguridad, porque npm dist-tag add sigue necesitando NPM_TOKEN, mientras que el repositorio público conserva publicación solo con OIDC
  • macOS Release público es solo de validación; cuando una etiqueta existe solo en una rama de versión pero el workflow se lanza desde main, establece public_release_branch=release/YYYY.M.D
  • la publicación privada real de mac debe pasar preflight_run_id y validate_run_id privados de mac exitosos
  • las rutas reales de publicación promocionan artefactos preparados en lugar de reconstruirlos de nuevo
• Para versiones estables de corrección como YYYY.M.D-N, el verificador posterior a la publicación también comprueba la misma ruta de actualización con prefijo temporal de YYYY.M.D a YYYY.M.D-N, de modo que las correcciones de versión no puedan dejar silenciosamente instalaciones globales antiguas en la carga base estable
• La comprobación previa de versión npm falla de forma cerrada salvo que el tarball incluya tanto dist/control-ui/index.html como una carga no vacía de dist/control-ui/assets/, para que no volvamos a publicar un panel de navegador vacío
• La verificación posterior a la publicación también comprueba que los entrypoints de plugins publicados y los metadatos del paquete estén presentes en el layout del registro instalado. Una versión que publica cargas de runtime de plugins ausentes falla el verificador postpublish y no puede promocionarse a latest.
• pnpm test:install:smoke también aplica el presupuesto de unpackedSize de npm pack en el tarball de actualización candidato, de modo que installer e2e detecte crecimiento accidental del paquete antes de la ruta de publicación de versión
• Si el trabajo de versión tocó planificación de CI, manifiestos de temporización de extensiones o matrices de pruebas de extensiones, regenera y revisa las salidas de matriz plugin-prerelease-extension-shard propiedad del planificador desde .github/workflows/plugin-prerelease.yml antes de aprobar, para que las notas de versión no describan un layout de CI obsoleto
• La preparación de versión estable de macOS también incluye las superficies del actualizador:
  • la versión de GitHub debe terminar con los .zip, .dmg y .dSYM.zip empaquetados
  • appcast.xml en main debe apuntar al nuevo zip estable después de publicar; el workflow privado de publicación de macOS lo commitea automáticamente o abre un PR de appcast cuando el push directo está bloqueado
  • la app empaquetada debe conservar un bundle id no debug, una URL de feed de Sparkle no vacía y un CFBundleVersion igual o superior al piso canónico de build de Sparkle para esa versión

​

Cajas de prueba de lanzamiento

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: ruta OpenAI/core live y Docker crítica para lanzamiento más rápida
• stable: minimum más cobertura estable de proveedor/backend para la aprobación de lanzamiento
• full: stable más cobertura amplia consultiva de proveedor/medios

# 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

• resumen de Full Release Validation que muestra la URL de ejecución CI despachada
• ejecución CI en verde en el SHA objetivo exacto
• nombres de fragmentos fallidos o lentos de los trabajos de CI al investigar regresiones
• artefactos de tiempos de Vitest como .artifacts/vitest-shard-timings.json cuando una ejecución necesita análisis de rendimiento

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

​

Docker

• smoke de instalación completo con el smoke de instalación global Bun lento activado
• preparación/reutilización de imagen smoke del Dockerfile raíz por SHA objetivo, con trabajos de smoke de QR, raíz/Gateway e instalador/Bun ejecutándose como fragmentos install-smoke separados
• rutas E2E del repositorio
• fragmentos Docker de ruta de lanzamiento: 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 y plugins-runtime-install-h
• cobertura OpenWebUI dentro del fragmento plugins-runtime-services cuando se solicita
• rutas divididas de instalación/desinstalación de Plugin incluido bundled-plugin-install-uninstall-0 a bundled-plugin-install-uninstall-23
• suites de proveedores live/E2E y cobertura de modelos live Docker cuando las comprobaciones de lanzamiento incluyen suites live

​

QA Lab

• ruta de paridad mock que compara la ruta candidata de OpenAI con la base Opus 4.6 usando el paquete de paridad agéntica
• perfil QA de Matrix live rápido usando el entorno qa-live-shared
• ruta QA de Telegram live usando leases de credenciales de Convex CI
• pnpm qa:otel:smoke cuando la telemetría de lanzamiento necesita prueba local explícita

​

Paquete

• source=npm: openclaw@beta, openclaw@latest o una versión exacta de lanzamiento de OpenClaw
• source=ref: empaquetar una rama, etiqueta o SHA de commit completo de package_ref confiable con el harness workflow_ref seleccionado
• source=url: descargar un .tgz HTTPS con package_sha256 requerido
• source=artifact: reutilizar un .tgz cargado por otra ejecución de GitHub Actions

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: carriles rápidos de instalación/canal/agente de paquete, red de Gateway y recarga de configuración
• package: contratos de paquete de instalación/actualización/reinicio/plugin, además de prueba de instalación en vivo de Skills de ClawHub; este es el valor predeterminado de comprobación de lanzamiento
• product: package más canales MCP, limpieza de cron/subagente, búsqueda web de OpenAI y OpenWebUI
• full: fragmentos de ruta de lanzamiento de Docker con OpenWebUI
• custom: lista exacta de docker_lanes para repeticiones enfocadas

​

Automatización de publicación de lanzamiento

1. Hacer checkout de la etiqueta de lanzamiento y resolver su SHA de commit.
2. Verificar que la etiqueta sea alcanzable desde main o release/*.
3. Ejecutar pnpm plugins:sync:check.
4. Despachar Plugin NPM Release con publish_scope=all-publishable y ref=<release-sha>.
5. Despachar Plugin ClawHub Release con el mismo alcance y SHA.
6. Despachar OpenClaw NPM Release con la etiqueta de lanzamiento, la dist-tag de npm y el preflight_run_id guardado.

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

​

Entradas del flujo de trabajo de NPM

• tag: etiqueta de lanzamiento requerida, como v2026.4.2, v2026.4.2-1 o v2026.4.2-beta.1; cuando preflight_only=true, también puede ser el SHA de commit completo de 40 caracteres de la rama del flujo de trabajo actual para un preflight solo de validación
• preflight_only: true solo para validación/compilación/paquete, false para la ruta de publicación real
• preflight_run_id: requerido en la ruta de publicación real para que el flujo de trabajo reutilice el tarball preparado de la ejecución de preflight exitosa
• npm_dist_tag: etiqueta npm de destino para la ruta de publicación; el valor predeterminado es beta

• tag: etiqueta de lanzamiento requerida; ya debe existir
• preflight_run_id: id de ejecución de preflight exitosa de OpenClaw NPM Release; requerido cuando publish_openclaw_npm=true
• npm_dist_tag: etiqueta npm de destino para el paquete de OpenClaw
• plugin_publish_scope: el valor predeterminado es all-publishable; usa selected solo para trabajos enfocados de reparación
• plugins: nombres de paquetes @openclaw/* separados por comas cuando plugin_publish_scope=selected
• publish_openclaw_npm: el valor predeterminado es true; establece false solo cuando uses el flujo de trabajo como orquestador de reparación solo de plugins
• wait_for_clawhub: el valor predeterminado es false para que la disponibilidad de npm no quede bloqueada por el sidecar de ClawHub; establece true solo cuando la finalización del flujo de trabajo deba incluir la finalización de ClawHub

• ref: rama, etiqueta o SHA de commit completo para validar. Las comprobaciones con secretos requieren que el commit resuelto sea alcanzable desde una rama de OpenClaw o etiqueta de lanzamiento.
• run_release_soak: optar por la prueba exhaustiva live/E2E, la ruta de lanzamiento de Docker y la prueba soak de upgrade-survivor desde todos los paquetes en comprobaciones de lanzamiento estables/predeterminadas. Se fuerza mediante release_profile=full.

• Las etiquetas estables y de corrección pueden publicarse en beta o latest
• Las etiquetas beta prerelease solo pueden publicarse en beta
• Para OpenClaw NPM Release, la entrada de SHA de commit completo solo se permite cuando preflight_only=true
• OpenClaw Release Checks y Full Release Validation siempre son solo de validación
• La ruta de publicación real debe usar el mismo npm_dist_tag usado durante el preflight; el flujo de trabajo verifica esos metadatos antes de que continúe la publicación

​

Secuencia de lanzamiento npm estable

1. Ejecuta OpenClaw NPM Release con preflight_only=true
   • Antes de que exista una etiqueta, puedes usar el SHA de commit completo de la rama del flujo de trabajo actual para una ejecución de prueba solo de validación del flujo de trabajo de preflight
2. Elige npm_dist_tag=beta para el flujo normal beta primero, o latest solo cuando quieras intencionalmente una publicación estable directa
3. Ejecuta Full Release Validation en la rama de lanzamiento, la etiqueta de lanzamiento o el SHA de commit completo cuando quieras CI normal más cobertura de live prompt cache, Docker, QA Lab, Matrix y Telegram desde un único flujo de trabajo manual
4. Si intencionalmente solo necesitas el grafo de pruebas normal determinista, ejecuta el flujo de trabajo manual CI en la ref de lanzamiento en su lugar
5. Guarda el preflight_run_id exitoso
6. Ejecuta OpenClaw Release Publish con la misma tag, el mismo npm_dist_tag y el preflight_run_id guardado; publica plugins externalizados en npm y ClawHub antes de promover el paquete npm de OpenClaw
7. Si el lanzamiento aterrizó en beta, usa el flujo de trabajo privado openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml para promover esa versión estable de beta a latest
8. Si el lanzamiento se publicó intencionalmente directamente en latest y beta debe seguir inmediatamente la misma compilación estable, usa ese mismo flujo de trabajo privado para apuntar ambas dist-tags a la versión estable, o deja que su sincronización programada de autorreparación mueva beta más tarde

​

Referencias públicas

• .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

​

Relacionado

• Canales de lanzamiento