diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index 451f57efa..89eff2261 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -5,10 +5,10 @@ read_when: summary: Публічні канали релізів, назви версій і періодичність title: Політика релізів x-i18n: - generated_at: "2026-04-10T23:44:31Z" + generated_at: "2026-04-12T22:00:22Z" model: gpt-5.4 provider: openai - source_hash: ca613d094c93670c012f0b79720fad0d5d85be802f54b0acb7a8f22aca5bde12 + source_hash: dffc1ee5fdbb20bd1bf4b3f817d497fc0d87f70ed6c669d324fea66dc01d0b0b source_path: reference/RELEASING.md workflow: 15 --- @@ -17,99 +17,126 @@ x-i18n: OpenClaw має три публічні канали релізів: -- stable: теговані релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запрошено +- stable: релізи з тегами, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано - beta: prerelease-теги, які публікуються в npm `beta` -- dev: рухома вершина `main` +- dev: поточна рухома вершина `main` ## Назви версій - Версія stable-релізу: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія stable-коригувального релізу: `YYYY.M.D-N` +- Версія stable-виправлення: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія beta-prerelease: `YYYY.M.D-beta.N` +- Версія beta prerelease: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не додавайте нулі попереду для місяця або дня -- `latest` означає поточний просунутий stable-реліз npm +- Не додавайте провідні нулі до місяця або дня +- `latest` означає поточний підвищений stable-реліз у npm - `beta` означає поточну ціль встановлення beta -- Stable і stable-коригувальні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку +- Stable-релізи та stable-виправлення за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлити публікацію на `latest` або пізніше підвищити перевірену beta-збірку - Кожен реліз OpenClaw постачається разом із npm-пакетом і застосунком для macOS ## Періодичність релізів - Релізи спочатку проходять через beta -- Stable іде лише після перевірки найновішої beta -- Детальна процедура релізу, затвердження, облікові дані та нотатки щодо відновлення - доступні лише для мейнтейнерів +- Stable виходить лише після перевірки останньої beta +- Детальна процедура релізу, затвердження, облікові дані та примітки щодо відновлення + доступні лише для maintainer-ів ## Передрелізна перевірка - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - артефакти релізу `dist/*` і збірка Control UI існували для кроку - перевірки пакування -- Запускайте `pnpm release:check` перед кожним тегованим релізом -- Передрелізна перевірка npm для main-гілки також запускає + артефакти релізу `dist/*` і бандл Control UI існували для кроку + перевірки pack +- Запускайте `pnpm release:check` перед кожним релізом із тегом +- Перевірки релізу тепер виконуються в окремому ручному workflow: + `OpenClaw Release Checks` +- Цей поділ є навмисним: він зберігає реальний шлях npm-релізу коротким, + детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються + у власному каналі, щоб не затримувати і не блокувати публікацію +- Перевірки релізу потрібно запускати з workflow ref для `main`, щоб + логіка workflow і секрети залишалися канонічними +- Цей workflow приймає або наявний тег релізу, або поточний повний + 40-символьний SHA коміту `main` +- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; для + старіших комітів релізу використовуйте тег релізу +- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту `main` без вимоги наявності запушеного тега +- Цей шлях SHA є лише для валідації і не може бути підвищений до реальної публікації +- У режимі SHA workflow синтезує `v` лише для + перевірки метаданих пакета; реальна публікація все одно потребує справжнього тега релізу +- Обидва workflows залишають реальний шлях публікації та підвищення на GitHub-hosted + runners, тоді як шлях валідації без змін стану може використовувати більші + Blacksmith Linux runners +- Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` - перед пакуванням tarball, використовуючи обидва секрети воркфлоу: - `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` + використовуючи обидва workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- Передрелізна перевірка npm-релізу більше не чекає окремий канал перевірок релізу - Перед затвердженням запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний beta/correction-тег) + (або відповідний тег beta/виправлення) - Після публікації в npm запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction-версію), щоб перевірити опублікований шлях + (або відповідну beta/версію виправлення), щоб перевірити опублікований шлях встановлення з реєстру в новому тимчасовому префіксі -- Автоматизація релізів для мейнтейнерів тепер використовує схему preflight-then-promote: - - справжня публікація в npm має пройти успішний npm `preflight_run_id` - - stable npm-релізи за замовчуванням ідуть у `beta` - - stable npm-публікацію можна явно націлити на `latest` через вхідні параметри воркфлоу - - stable npm-просування з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному воркфлоу `OpenClaw NPM Release` - - для цього режиму просування все одно потрібен дійсний `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` виконується окремо від trusted publishing +- Автоматизація релізів maintainer-ів тепер використовує схему preflight-then-promote: + - реальна публікація в npm має пройти успішний npm `preflight_run_id` + - stable npm-релізи за замовчуванням націлюються на `beta` + - stable npm-публікація може явно націлюватися на `latest` через вхід workflow + - підвищення stable npm з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному workflow `OpenClaw NPM Release` + - цей режим підвищення все ще потребує дійсного `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` виконується окремо від trusted publishing - публічний `macOS Release` призначений лише для валідації - - справжня приватна mac-публікація має пройти успішні приватні mac + - реальна приватна mac-публікація має пройти успішні приватні mac `preflight_run_id` і `validate_run_id` - - справжні шляхи публікації просувають підготовлені артефакти замість того, щоб - повторно збирати їх знову -- Для stable-коригувальних релізів на кшталт `YYYY.M.D-N`, post-publish verifier + - реальні шляхи публікації підвищують уже підготовлені артефакти замість їх повторного збирання +- Для stable-виправлень на кшталт `YYYY.M.D-N` post-publish verifier також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`, - щоб коригувальні релізи не могли непомітно залишити старіші глобальні встановлення на - базовому stable-навантаженні -- Передрелізна перевірка npm завершується з відмовою за замовчуванням, якщо tarball не містить і - `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, + щоб виправлення релізу не могли непомітно залишити старі глобальні встановлення на + базовому stable-вмісті +- Передрелізна перевірка npm-релізу завершується помилкою за замовчуванням, якщо tarball не містить + і `dist/control-ui/index.html`, і непорожній вміст `dist/control-ui/assets/`, щоб ми знову не випустили порожню панель браузера -- Якщо робота над релізом зачіпала планування CI, маніфести таймінгу розширень або - матриці тестування розширень, перед затвердженням згенеруйте наново й перегляньте - виходи матриці воркфлоу `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`, - щоб нотатки до релізу не описували застарілу структуру CI -- Готовність stable-релізу macOS також включає поверхні оновлювача: - - GitHub-реліз зрештою має містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - - `appcast.xml` у `main` має після публікації вказувати на новий stable zip - - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed - URL і `CFBundleVersion`, не нижчий за канонічний мінімальний рівень збірки Sparkle +- Якщо робота над релізом зачепила планування CI, маніфести часу виконання extensions або + матриці тестування extensions, перед затвердженням згенеруйте заново та перегляньте + workflow matrix outputs, якими керує planner, + `checks-node-extensions` з `.github/workflows/ci.yml`, щоб примітки до релізу не + описували застарілу структуру CI +- Готовність stable-релізу для macOS також охоплює поверхні оновлення: + - GitHub-реліз зрештою має містити паковані `.zip`, `.dmg` і `.dSYM.zip` + - `appcast.xml` у `main` після публікації має вказувати на новий stable zip + - пакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище канонічного мінімального Sparkle build для цієї версії релізу -## Вхідні параметри воркфлоу NPM +## Вхідні параметри workflow NPM -`OpenClaw NPM Release` приймає такі вхідні параметри, якими керує оператор: +`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри: - `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або - `v2026.4.2-beta.1` + `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний + повний 40-символьний SHA коміту `main` для передрелізної перевірки лише з валідацією - `preflight_only`: `true` лише для валідації/збирання/пакування, `false` для - справжнього шляху публікації -- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб воркфлоу повторно використав - підготовлений tarball з успішного передрелізного запуску + реального шляху публікації +- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав + підготовлений tarball з успішного запуску передрелізної перевірки - `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta` -- `promote_beta_to_latest`: `true`, щоб пропустити публікацію і перемістити вже опубліковану - stable-збірку `beta` до `latest` +- `promote_beta_to_latest`: `true`, щоб пропустити публікацію й перемістити вже опубліковану + stable beta-збірку на `latest` + +`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри: + +- `ref`: наявний тег релізу або поточний повний 40-символьний SHA коміту `main` + для перевірки Правила: -- Stable і correction-теги можуть публікуватися або в `beta`, або в `latest` +- Stable-теги та теги виправлень можуть публікуватися або в `beta`, або в `latest` - Beta prerelease-теги можуть публікуватися лише в `beta` -- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки; - воркфлоу перевіряє ці метадані перед продовженням публікації -- Режим просування має використовувати stable або correction-тег, `preflight_only=false`, +- Повний SHA коміту дозволений лише коли `preflight_only=true` +- Режим SHA коміту для перевірок релізу також вимагає поточний HEAD `origin/main` +- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки; + workflow перевіряє ці метадані перед продовженням публікації +- Режим підвищення має використовувати stable-тег або тег виправлення, `preflight_only=false`, порожній `preflight_run_id` і `npm_dist_tag=beta` -- Режим просування також вимагає дійсний `NPM_TOKEN` у середовищі `npm-release`, +- Режим підвищення також вимагає дійсний `NPM_TOKEN` у середовищі `npm-release`, оскільки `npm dist-tag add` усе ще потребує звичайної npm-автентифікації ## Послідовність stable npm-релізу @@ -117,29 +144,36 @@ OpenClaw має три публічні канали релізів: Під час випуску stable npm-релізу: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` -2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку, або `latest` лише - якщо ви свідомо хочете прямої stable-публікації -3. Збережіть успішний `preflight_run_id` -4. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим + - До появи тега ви можете використовувати поточний повний SHA коміту `main` для + dry run передрелізного workflow лише з валідацією +2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише + коли ви навмисно хочете пряму stable-публікацію +3. Окремо запустіть `OpenClaw Release Checks` з тим самим тегом або + повним поточним SHA `main`, якщо вам потрібне live-покриття prompt cache + - Це навмисно окремо, щоб live-покриття залишалося доступним без + повторного поєднання довготривалих або нестабільних перевірок із workflow публікації +4. Збережіть успішний `preflight_run_id` +5. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id` -5. Якщо реліз потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з +6. Якщо реліз потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з тим самим stable `tag`, `promote_beta_to_latest=true`, `preflight_only=false`, порожнім `preflight_run_id` і `npm_dist_tag=beta`, коли захочете перемістити цю опубліковану збірку до `latest` -Режим просування все ще вимагає затвердження середовища `npm-release` і +Режим підвищення все ще потребує затвердження середовища `npm-release` і дійсного `NPM_TOKEN` у цьому середовищі. -Це залишає як шлях прямої публікації, так і beta-first шлях просування +Це зберігає як шлях прямої публікації, так і шлях підвищення beta-first задокументованими та видимими для оператора. ## Публічні посилання - [`.github/workflows/openclaw-npm-release.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-npm-release.yml) +- [`.github/workflows/openclaw-release-checks.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-release-checks.yml) - [`scripts/openclaw-npm-release-check.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/openclaw-npm-release-check.ts) - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Мейнтейнери використовують приватну документацію з релізів у +Maintainer-и використовують приватну документацію релізів у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) -як фактичний runbook. +для фактичного runbook.