Політика випусків

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: теговані випуски, які за замовчуванням публікуються в npm beta, або в npm latest, коли це явно запитано
• beta: передрелізні теги, які публікуються в npm beta
• dev: рухома вершина main

​

Назви версій

• Версія стабільного випуску: YYYY.M.D
  • Git-тег: vYYYY.M.D
• Версія стабільного корекційного випуску: YYYY.M.D-N
  • Git-тег: vYYYY.M.D-N
• Передрелізна beta-версія: YYYY.M.D-beta.N
  • Git-тег: vYYYY.M.D-beta.N
• Не доповнюйте місяць або день нулями
• latest означає поточний просунутий стабільний npm-випуск
• beta означає поточну ціль встановлення beta
• Стабільні та стабільні корекційні випуски за замовчуванням публікуються в npm beta; оператори випуску можуть явно націлити їх на latest або просунути перевірену beta-збірку пізніше
• Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS; beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а збирання/підпис/нотаризацію mac-застосунку залишають для стабільного випуску, якщо це явно не запитано

​

Каденція випусків

• Випуски рухаються спочатку через beta
• Стабільний випуск іде лише після перевірки останньої beta
• Maintainer-и зазвичай створюють випуски з гілки release/YYYY.M.D, створеної з поточного main, щоб перевірка випуску та виправлення не блокували нову розробку в main
• Якщо beta-тег уже було надіслано або опубліковано й він потребує виправлення, maintainer-и створюють наступний тег -beta.N замість видалення або повторного створення старого beta-тега
• Детальна процедура випуску, погодження, облікові дані та нотатки з відновлення доступні лише maintainer-ам

​

Контрольний список оператора випуску

1. Почніть із поточного main: отримайте найновіші зміни, підтвердьте, що цільовий коміт надіслано, і підтвердьте, що поточний CI main достатньо зелений, щоб створити від нього гілку.
2. Перепишіть верхній розділ CHANGELOG.md з реальної історії комітів за допомогою /changelog, залиште записи орієнтованими на користувача, закомітьте його, надішліть його та виконайте rebase/pull ще раз перед створенням гілки.
3. Перегляньте записи сумісності випуску в src/plugins/compat/registry.ts і src/commands/doctor/shared/deprecation-compat.ts. Видаляйте застарілу сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її навмисно збережено.
4. Створіть release/YYYY.M.D з поточного main; не виконуйте звичайну роботу над випуском безпосередньо в main.
5. Підвищте кожне потрібне місце з версією для запланованого тега, потім виконайте pnpm release:prep. Це оновлює версії Plugin, інвентар Plugin, схему конфігурації, метадані конфігурації вбудованих каналів, базову лінію документації конфігурації, експорти Plugin SDK і базову лінію API Plugin SDK у правильному порядку. Закомітьте будь-який згенерований дрейф перед тегуванням. Потім запустіть локальний детермінований preflight: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build і pnpm release:check.
6. Запустіть OpenClaw NPM Release з preflight_only=true. Поки тега не існує, повний 40-символьний SHA гілки випуску дозволено для preflight лише з метою перевірки. Збережіть успішний preflight_run_id.
7. Запустіть усі передрелізні тести через Full Release Validation для гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
8. Якщо перевірка не вдається, виправте в гілці випуску та повторно запустіть найменший невдалий файл, канал, workflow job, профіль пакета, provider або allowlist моделі, що доводить виправлення. Повторно запускайте повний umbrella лише тоді, коли змінена поверхня робить попередні докази застарілими.
9. Для beta позначте vYYYY.M.D-beta.N, потім запустіть OpenClaw Release Publish з відповідної гілки release/YYYY.M.D. Він перевіряє pnpm plugins:sync:check, паралельно надсилає всі публіковані пакети Plugin до npm і той самий набір до ClawHub, а потім просуває підготовлений preflight-артефакт OpenClaw npm з відповідним dist-tag, щойно публікація Plugin в npm завершується успішно. Після успішного завершення дочірнього процесу публікації OpenClaw npm він створює або оновлює відповідну сторінку GitHub release/prerelease з повного відповідного розділу CHANGELOG.md. Стабільні випуски, опубліковані в npm latest, стають найновішим випуском GitHub; стабільні maintenance-випуски, залишені в npm beta, створюються з GitHub latest=false. Публікація ClawHub може ще тривати, поки публікується OpenClaw npm, але workflow публікації випуску одразу виводить ідентифікатори дочірніх запусків. За замовчуванням він не чекає на ClawHub після його dispatch, тому доступність OpenClaw npm не блокується повільнішими погодженнями ClawHub або роботою registry; встановіть wait_for_clawhub=true, коли ClawHub має блокувати завершення workflow. Шлях ClawHub повторює тимчасові збої встановлення CLI-залежностей, публікує Plugin-и, що пройшли preview, навіть коли одна preview-комірка має нестабільний збій, і завершується перевіркою registry для кожної очікуваної версії Plugin, щоб часткові публікації залишалися видимими та придатними для повтору. Після публікації виконайте pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> для перевірки GitHub prerelease, npm dist-tag beta, цілісності npm, опублікованого шляху встановлення, точних версій ClawHub, артефактів ClawHub і висновків дочірніх workflow однією командою. Додайте --rerun-failed-clawhub, коли sidecar ClawHub завершився невдало лише в job-ах, які можна повторити, і його слід повторно запустити на місці. Потім запустіть post-publish package acceptance проти опублікованого пакета openclaw@YYYY.M.D-beta.N або openclaw@beta. Якщо надісланий або опублікований prerelease потребує виправлення, створіть наступний відповідний номер prerelease; не видаляйте й не переписуйте старий prerelease.
10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має потрібні докази перевірки. Публікація stable в npm також проходить через OpenClaw Release Publish, повторно використовуючи успішний preflight-артефакт через preflight_run_id; готовність стабільного випуску macOS також потребує упакованих .zip, .dmg, .dSYM.zip і оновленого appcast.xml у main. Приватний workflow публікації macOS автоматично публікує підписаний appcast у публічний main після перевірки release assets; якщо branch protection блокує прямий push, він відкриває або оновлює PR appcast.
11. Після публікації запустіть npm post-publish verifier, опційний автономний published-npm Telegram E2E, коли вам потрібен післяпублікаційний доказ каналу, просування dist-tag за потреби, перевірте згенеровану сторінку GitHub release і виконайте кроки оголошення випуску.

​

Release preflight

• Запустіть pnpm check:test-types перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом pnpm check
• Запустіть pnpm check:architecture перед передрелізною перевіркою, щоб ширші перевірки циклів імпортів і меж архітектури були зеленими поза швидшим локальним шлюзом
• Запустіть pnpm build && pnpm ui:build перед pnpm release:check, щоб очікувані релізні артефакти dist/* і бандл Control UI існували для кроку перевірки пакування
• Запустіть pnpm release:prep після підвищення версії в корені й перед тегуванням. Він запускає кожен детермінований релізний генератор, який часто розходиться після зміни версії/конфігурації/API: версії Plugin, інвентар Plugin, схему базової конфігурації, метадані конфігурації вбудованих каналів, базову лінію документації конфігурації, експорти plugin SDK і базову лінію API plugin SDK. pnpm release:check повторно запускає ці захисні перевірки в режимі перевірки та повідомляє про кожен знайдений збій дрейфу згенерованих файлів за один прохід перед запуском перевірок релізу пакета.
• Запустіть ручний workflow Full Release Validation перед затвердженням релізу, щоб запустити всі передрелізні тестові середовища з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний CI і запускає OpenClaw Release Checks для install smoke, приймання пакета, крос-ОС перевірок пакета, паритету QA Lab, Matrix і Telegram lanes. Стабільні/типові запуски тримають вичерпні live/E2E і Docker release-path soak за run_release_soak=true; release_profile=full примусово вмикає soak. З release_profile=full і rerun_group=all він також запускає package Telegram E2E проти артефакту release-package-under-test з release checks. Надайте release_package_spec після публікації beta, щоб повторно використати відвантажений npm-пакет у release checks, Package Acceptance і package Telegram E2E без перебудови релізного tarball. Надайте npm_telegram_package_spec лише тоді, коли Telegram має використовувати інший опублікований пакет, ніж решта release validation. Надайте package_acceptance_package_spec, коли Package Acceptance має використовувати інший опублікований пакет, ніж специфікація релізного пакета. Надайте evidence_package_spec, коли приватний звіт доказів має довести, що валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. Приклад: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• Запустіть ручний workflow Package Acceptance, коли потрібен побічний доказ для кандидата пакета, поки релізна робота триває. Використовуйте source=npm для openclaw@beta, openclaw@latest або точної релізної версії; source=ref, щоб запакувати довірену гілку/тег/SHA package_ref з поточним harness workflow_ref; source=url для HTTPS tarball з обов’язковим SHA-256; або source=artifact для tarball, завантаженого іншим запуском GitHub Actions. Workflow визначає кандидата як package-under-test, повторно використовує Docker E2E release scheduler проти цього tarball і може запускати Telegram QA проти того самого tarball з telegram_mode=mock-openai або telegram_mode=live-frontier. Коли вибрані Docker lanes містять published-upgrade-survivor, артефакт пакета є кандидатом, а published_upgrade_survivor_baseline вибирає опубліковану базову лінію. update-restart-auth використовує пакет-кандидат як встановлений CLI і як package-under-test, тож він перевіряє managed restart path команди оновлення кандидата. Приклад: 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 Поширені профілі:
  • smoke: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
  • package: artifact-native lanes пакета/оновлення/перезапуску/Plugin без OpenWebUI або live ClawHub
  • product: профіль package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI
  • full: Docker release-path chunks з OpenWebUI
  • custom: точний вибір docker_lanes для сфокусованого повторного запуску
• Запустіть ручний workflow CI напряму, коли потрібне лише повне звичайне покриття CI для релізного кандидата. Ручні запуски CI обходять scoped changed і примусово запускають Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, check, check-additional, build smoke, перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n lanes. Приклад: gh workflow run ci.yml --ref release/YYYY.M.D
• Запустіть pnpm qa:otel:smoke під час валідації релізної телеметрії. Він перевіряє QA-lab через локальний OTLP/HTTP receiver і верифікує експортовані назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому колекторі.
• Запустіть pnpm release:check перед кожним тегованим релізом
• Запустіть OpenClaw Release Publish для mutating publish sequence після того, як тег існує. Запускайте його з release/YYYY.M.D (або main, коли публікуєте тег, досяжний з main), передайте релізний тег і успішний OpenClaw npm preflight_run_id, і зберігайте типовий scope публікації Plugin all-publishable, якщо ви не виконуєте навмисний сфокусований repair. Workflow серіалізує публікацію Plugin в npm, публікацію Plugin в ClawHub і публікацію OpenClaw в npm, щоб основний пакет не був опублікований раніше за свої зовнішні plugins.
• Release checks тепер виконуються в окремому ручному workflow: OpenClaw Release Checks
• OpenClaw Release Checks також запускає lane mock parity QA Lab плюс швидкий live-профіль Matrix і Telegram QA lane перед затвердженням релізу. Live lanes використовують середовище qa-live-shared; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний workflow QA-Lab - All Lanes з matrix_profile=all і matrix_shards=true, коли потрібен повний інвентар Matrix transport, media і E2EE паралельно.
• Крос-ОС валідація встановлення та runtime оновлення є частиною публічних OpenClaw Release Checks і Full Release Validation, які напряму викликають reusable workflow .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Це розділення навмисне: тримайте реальний шлях npm-релізу коротким, детермінованим і зосередженим на артефактах, тоді як повільніші live checks залишаються у своїй окремій lane, щоб вони не затримували й не блокували publish
• Release checks із секретами слід запускати через Full Release Validation або з workflow ref main/release, щоб логіка workflow і секрети залишалися контрольованими
• OpenClaw Release Checks приймає гілку, тег або повний SHA коміту, якщо визначений коміт досяжний з гілки OpenClaw або релізного тегу
• Validation-only preflight OpenClaw NPM Release також приймає поточний повний 40-символьний SHA коміту workflow-branch без вимоги запушеного тегу
• Цей шлях SHA призначений лише для валідації та не може бути підвищений до реального publish
• У режимі SHA workflow синтезує v<package.json version> лише для перевірки метаданих пакета; реальний publish усе одно потребує справжнього релізного тегу
• Обидва workflows тримають реальний шлях publish і promotion на GitHub-hosted runners, тоді як немутуючий шлях валідації може використовувати більші Blacksmith Linux runners
• Цей workflow запускає OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache з використанням обох workflow secrets OPENAI_API_KEY і ANTHROPIC_API_KEY
• npm release preflight більше не чекає на окрему lane release checks
• Перед локальним тегуванням релізного кандидата запустіть RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check. Helper запускає швидкі релізні guardrails, перевірки релізу Plugin npm/ClawHub, build, UI build і release:openclaw:npm:check у порядку, який виявляє поширені помилки, що блокують затвердження, до запуску workflow публікації GitHub.
• Запустіть RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (або відповідний beta/correction tag) перед затвердженням
• Після npm publish запустіть node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (або відповідну beta/correction version), щоб перевірити шлях встановлення з опублікованого registry у свіжий temp prefix
• Після beta publish запустіть 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 щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. Локальні одноразові запуски maintainer можуть пропустити Convex vars і передати три env credentials OPENCLAW_QA_TELEGRAM_* напряму.
• Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте pnpm release:beta-smoke -- --beta betaN. Helper запускає Parallels npm update/fresh-target validation, запускає NPM Telegram Beta E2E, опитує точний workflow run, завантажує артефакт і друкує звіт Telegram.
• Maintainers можуть запускати ту саму post-publish check з GitHub Actions через ручний workflow NPM Telegram Beta E2E. Він навмисно лише ручний і не запускається під час кожного merge.
• Автоматизація релізів maintainer тепер використовує preflight-then-promote:
  • реальний npm publish має пройти успішний npm preflight_run_id
  • реальний npm publish має запускатися з тієї самої гілки main або release/YYYY.M.D, що й успішний preflight run
  • stable npm releases типово використовують beta
  • stable npm publish може явно націлюватися на latest через workflow input
  • token-based мутація npm dist-tag тепер живе в openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml для безпеки, тому що npm dist-tag add досі потребує NPM_TOKEN, тоді як публічний repo зберігає publish лише через OIDC
  • публічний macOS Release є validation-only; коли тег існує лише на release branch, але workflow запускається з main, задайте public_release_branch=release/YYYY.M.D
  • реальний приватний mac publish має пройти успішні приватні mac preflight_run_id і validate_run_id
  • реальні publish paths підвищують підготовлені артефакти замість того, щоб перебудовувати їх знову
• Для stable correction releases на кшталт YYYY.M.D-N post-publish verifier також перевіряє той самий шлях оновлення temp-prefix з YYYY.M.D до YYYY.M.D-N, щоб release corrections не могли непомітно залишити старіші глобальні встановлення на базовому stable payload
• npm release preflight fail-closed, якщо tarball не містить одночасно dist/control-ui/index.html і непорожній payload dist/control-ui/assets/, щоб ми знову не відвантажили порожню браузерну dashboard
• Post-publish verification також перевіряє, що опубліковані entrypoints Plugin і метадані пакета присутні у встановленому registry layout. Реліз, який відвантажує відсутні runtime payloads Plugin, провалює postpublish verifier і не може бути підвищений до latest.
• pnpm test:install:smoke також забезпечує бюджет unpackedSize npm pack для candidate update tarball, тож installer e2e виявляє випадкове pack bloat до release publish path
• Якщо релізна робота торкалася планування CI, timing manifests extension або test matrices extension, перегенеруйте й перегляньте outputs матриці plugin-prerelease-extension-shard, що належать planner, з .github/workflows/plugin-prerelease.yml перед затвердженням, щоб release notes не описували застарілий CI layout
• Stable macOS release readiness також включає updater surfaces:
  • GitHub release має зрештою містити запаковані .zip, .dmg і .dSYM.zip
  • appcast.xml у main має вказувати на новий stable zip після publish; приватний macOS publish workflow комітить його автоматично або відкриває appcast PR, коли direct push заблоковано
  • запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed URL і CFBundleVersion на рівні або вище канонічного Sparkle build floor для цієї релізної версії

​

Релізні тестові бокси

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: найшвидший критичний для релізу OpenAI/core live і Docker шлях
• stable: minimum плюс стабільне покриття provider/backend для схвалення релізу
• full: stable плюс широке консультативне покриття provider/media

# 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, що показує URL запущеного CI run
• зелений CI run на точному цільовому SHA
• назви збійних або повільних shards із CI jobs під час розслідування регресій
• артефакти таймінгів Vitest, як-от .artifacts/vitest-shard-timings.json, коли запуск потребує аналізу продуктивності

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

​

Docker

• повний install smoke з увімкненим повільним Bun global install smoke
• підготовку/повторне використання smoke image root Dockerfile за цільовим SHA, з QR, root/gateway і installer/Bun smoke jobs, що запускаються як окремі install-smoke shards
• repository E2E лінії
• 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 і plugins-runtime-install-h
• покриття OpenWebUI всередині chunk plugins-runtime-services, коли запитано
• розділені лінії встановлення/видалення bundled plugin bundled-plugin-install-uninstall-0 до bundled-plugin-install-uninstall-23
• live/E2E provider suites і Docker live model coverage, коли релізні перевірки включають live suites

​

QA Lab

• mock parity лінію, що порівнює OpenAI candidate lane з базовою лінією Opus 4.6 за допомогою agentic parity pack
• швидкий live Matrix QA profile з використанням середовища qa-live-shared
• live Telegram QA lane з використанням Convex CI credential leases
• pnpm qa:otel:smoke, коли релізній telemetry потрібен явний локальний доказ

​

Пакет

• source=npm: openclaw@beta, openclaw@latest або точна релізна версія OpenClaw
• source=ref: запакувати довірену package_ref гілку, тег або повний commit SHA з вибраним workflow_ref harness
• source=url: завантажити HTTPS .tgz з обов’язковим package_sha256
• source=artifact: повторно використати .tgz, завантажений іншим GitHub Actions run

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: швидкі смуги встановлення пакета/каналу/агента, мережі Gateway і перезавантаження конфігурації
• package: контракти встановлення/оновлення/перезапуску/пакета Plugin плюс живе підтвердження встановлення Skills із ClawHub; це стандарт релізної перевірки
• product: package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI
• full: Docker-частини релізного шляху з OpenWebUI
• custom: точний список docker_lanes для сфокусованих повторних запусків

​

Автоматизація публікації релізу

1. Отримати релізний тег і розв’язати його commit SHA.
2. Перевірити, що тег досяжний із main або release/*.
3. Запустити pnpm plugins:sync:check.
4. Запустити Plugin NPM Release із publish_scope=all-publishable і ref=<release-sha>.
5. Запустити Plugin ClawHub Release з тим самим scope і SHA.
6. Запустити OpenClaw NPM Release із релізним тегом, npm dist-tag і збереженим 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 workflow

• tag: обов’язковий релізний тег, як-от v2026.4.2, v2026.4.2-1 або v2026.4.2-beta.1; коли preflight_only=true, це також може бути поточний повний 40-символьний commit SHA гілки workflow для preflight лише з валідацією
• preflight_only: true лише для валідації/збірки/пакування, false для реального шляху публікації
• preflight_run_id: обов’язковий на реальному шляху публікації, щоб workflow повторно використав підготовлений tarball з успішного preflight-запуску
• npm_dist_tag: цільовий npm tag для шляху публікації; стандартно beta

• tag: обов’язковий релізний тег; має вже існувати
• preflight_run_id: ідентифікатор успішного preflight-запуску OpenClaw NPM Release; обов’язковий, коли publish_openclaw_npm=true
• npm_dist_tag: цільовий npm tag для пакета OpenClaw
• plugin_publish_scope: стандартно all-publishable; використовуйте selected лише для сфокусованого ремонту
• plugins: розділені комами назви пакетів @openclaw/*, коли plugin_publish_scope=selected
• publish_openclaw_npm: стандартно true; встановлюйте false лише коли використовуєте workflow як оркестратор ремонту тільки для Plugin
• wait_for_clawhub: стандартно false, щоб доступність npm не блокувалася sidecar ClawHub; встановлюйте true лише коли завершення workflow має включати завершення ClawHub

• ref: гілка, тег або повний commit SHA для валідації. Перевірки із секретами вимагають, щоб розв’язаний commit був досяжний із гілки OpenClaw або релізного тегу.
• run_release_soak: увімкнення вичерпного live/E2E, Docker release-path і all-since upgrade-survivor soak на стабільних/стандартних релізних перевірках. Примусово вмикається через release_profile=full.

• Стабільні та корекційні теги можуть публікуватися або до beta, або до latest
• Beta prerelease теги можуть публікуватися лише до beta
• Для OpenClaw NPM Release введення повного commit SHA дозволене лише коли preflight_only=true
• OpenClaw Release Checks і Full Release Validation завжди є лише валідаційними
• Реальний шлях публікації має використовувати той самий npm_dist_tag, що використовувався під час preflight; workflow перевіряє ці метадані перед продовженням публікації

​

Послідовність стабільного npm-релізу

1. Запустіть OpenClaw NPM Release із preflight_only=true
   • До появи тегу можна використати поточний повний commit SHA гілки workflow для сухого запуску preflight workflow лише з валідацією
2. Оберіть npm_dist_tag=beta для звичайного потоку beta-first або latest лише коли навмисно хочете пряму стабільну публікацію
3. Запустіть Full Release Validation на релізній гілці, релізному тегу або повному commit SHA, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab, Matrix і Telegram з одного ручного workflow
4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть ручний workflow CI на релізному ref
5. Збережіть успішний preflight_run_id
6. Запустіть OpenClaw Release Publish з тим самим tag, тим самим npm_dist_tag і збереженим preflight_run_id; він публікує екстерналізовані Plugin до npm і ClawHub перед просуванням npm-пакета OpenClaw
7. Якщо реліз потрапив на beta, використовуйте приватний workflow openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml, щоб просунути цю стабільну версію з beta до latest
8. Якщо реліз навмисно опубліковано безпосередньо до latest і beta має негайно вказувати на ту саму стабільну збірку, використовуйте той самий приватний workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій self-healing синхронізації пізніше перемістити beta

​

Публічні посилання

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

​

Пов’язане

• Релізні канали