Guía de lanzamiento OpenClaw: Publica versiones en macOS

¿Alguna vez has sentido la presión de pulsar el botón de publicar sin saber si el paquete de npm está completo o si el build de macOS funcionará correctamente? Gestionar lanzamientos técnicos requiere un orden estricto para evitar errores que afecten a los usuarios y para mantener la integridad del código.

En OpenClaw, seguimos una política clara para que siempre sepas qué versión estás usando y qué esperar de cada actualización. Utilizamos tres canales de lanzamiento públicos:

• stable: versiones etiquetadas que se publican en npm latest y replican la misma versión en beta, a menos que beta ya apunte a un pre-lanzamiento más reciente.
• beta: etiquetas de pre-lanzamiento que se publican en npm beta.
• dev: el estado actual de la rama main.

Nomenclatura de versiones

• Versión de lanzamiento Stable: YYYY.M.D
  • Git tag: vYYYY.M.D
• Versión de corrección Stable: YYYY.M.D-N
  • Git tag: vYYYY.M.D-N
• Versión de pre-lanzamiento Beta: YYYY.M.D-beta.N
  • Git tag: vYYYY.M.D-beta.N
• No uses ceros iniciales para el mes o el día.
• latest se refiere al lanzamiento stable actual en npm.
• beta es el objetivo de instalación beta actual, que puede apuntar al pre-lanzamiento activo o a la última versión stable promocionada.
• Los lanzamientos stable y sus correcciones se publican en npm latest y también actualizan la etiqueta beta de npm a esa misma versión (no beta) tras la promoción, excepto si beta ya apunta a un pre-lanzamiento más nuevo.
• Cada lanzamiento de OpenClaw entrega el paquete de npm y la aplicación de macOS de forma conjunta.

Cadencia de lanzamientos

• Los lanzamientos se mueven primero a beta.
• La versión stable solo se publica después de que la última beta ha sido validada.
• Los procedimientos detallados de lanzamiento, las aprobaciones, las credenciales y las notas de recuperación son de acceso exclusivo para mantenedores.

Verificación previa al lanzamiento

• Ejecuta pnpm build && pnpm ui:build antes de pnpm release:check para que existan los artefactos de dist/* y el bundle de la Control UI necesarios para la validación del paquete.

pnpm build && pnpm ui:build

• Ejecuta pnpm release:check antes de cada lanzamiento etiquetado.

pnpm release:check

• Ejecuta el siguiente comando (o la etiqueta de beta/corrección correspondiente) antes de la aprobación:

RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts

• Tras publicar en npm, ejecuta este comando para verificar la ruta de instalación en el registro en un prefijo temporal limpio:

node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D

• La automatización de lanzamientos para mantenedores ahora usa el flujo de verificar y luego promocionar:
  • La publicación real en npm debe superar un preflight_run_id de npm exitoso.
  • El macOS Release público es solo para validación.
  • La publicación privada real de mac debe superar un preflight_run_id y un validate_run_id privados de mac exitosos.
  • Las rutas de publicación reales promocionan artefactos ya preparados en lugar de reconstruirlos.
• Para lanzamientos de corrección stable como YYYY.M.D-N, el verificador post-publicación también comprueba la ruta de actualización en el prefijo temporal desde YYYY.M.D a YYYY.M.D-N. Esto evita que las correcciones dejen instalaciones globales antiguas con el contenido stable base.
• La verificación previa de npm falla si el tarball no incluye tanto dist/control-ui/index.html como un contenido no vacío en dist/control-ui/assets/. Así evitamos enviar un dashboard de navegador vacío.
• Si el trabajo de lanzamiento afectó a la planificación de CI, manifiestos de tiempo de extensiones, matrices de pruebas rápidas o la configuración de shards, regenera y revisa el plan mediante:

node scripts/ci-write-manifest-outputs.mjs --workflow ci

• La preparación del lanzamiento stable para macOS también incluye los elementos del actualizador:
  • El lanzamiento en GitHub debe terminar con los archivos empaquetados .zip, .dmg, .dSYM.zip y sus firmas correspondientes.
  • appcast.xml en main debe apuntar al nuevo zip stable tras la publicación.
  • La aplicación empaquetada debe mantener un bundle id que no sea de depuración, una URL de feed de Sparkle no vacía, un CFBundleVersion adecuado y los permisos de ejecución correctos.

Referencias públicas

• .github/workflows/openclaw-npm-release.yml
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

Los mantenedores usan la documentación privada de lanzamientos en openclaw/maintainers/release/README.md como guía de ejecución real.

Siguientes pasos

• Revisa nuestra guía de contribución para Node.js.
• Explora la configuración del Gateway en producción.

AI Setup Assistant