diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index 451166a14..0a53c5a3e 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,181 +1,196 @@ --- read_when: - - Шукаєте визначення публічних каналів випусків - - Шукаєте назви версій і частоту випусків -summary: Публічні канали випусків, назви версій і частота випусків + - Шукаю визначення публічних каналів випусків + - Шукаю найменування версій і частоту випусків +summary: Публічні канали випусків, найменування версій і частота випусків title: Політика випусків x-i18n: - generated_at: "2026-04-20T14:13:28Z" + generated_at: "2026-04-21T04:35:05Z" model: gpt-5.4 provider: openai - source_hash: 281b3fd1764c60cb35a25a12c338595020d7c04bcb662e96c4131193a0607537 + source_hash: 356844708f6ecdae4acfcce853ce16ae962914a9fdd1cfc38a22ac4c439ba172 source_path: reference/RELEASING.md workflow: 15 --- # Політика випусків -OpenClaw має три публічні канали випусків: +OpenClaw має три публічні гілки випусків: - stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано - beta: теги попередніх випусків, які публікуються в npm `beta` - dev: рухома вершина `main` -## Назви версій +## Найменування версій -- Версія стабільного випуску: `YYYY.M.D` +- Версія stable-випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія випуску стабільного виправлення: `YYYY.M.D-N` +- Версія stable-випуску з виправленням: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія beta prerelease: `YYYY.M.D-beta.N` +- Версія beta-попереднього випуску: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не додавайте нулі попереду для місяця або дня -- `latest` означає поточний стабільний випуск npm, який було підвищено +- Не додавайте нулі на початку місяця або дня +- `latest` означає поточний просунутий stable-випуск npm - `beta` означає поточну ціль встановлення beta -- Стабільні випуски та випуски стабільних виправлень за замовчуванням публікуються в npm `beta`; оператори випусків можуть явно націлюватися на `latest` або підвищити перевірену beta-збірку пізніше -- Кожен випуск OpenClaw одночасно постачає npm package і застосунок macOS +- Stable-випуски та stable-випуски з виправленнями за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлити `latest` або просунути перевірену beta-збірку пізніше +- Кожен stable-випуск OpenClaw постачається разом із npm-пакетом і застосунком для macOS; + beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/package, а + збірка/підпис/нотаризація застосунку для macOS резервуються для stable, якщо + інше не запитано явно ## Частота випусків - Випуски спочатку проходять через beta -- Stable з’являється лише після перевірки останньої beta -- Детальна процедура випуску, затвердження, облікові дані та примітки щодо відновлення доступні - лише для супроводжувачів +- Stable іде лише після перевірки останньої beta +- Зазвичай супроводжувачі створюють випуски з гілки `release/YYYY.M.D`, створеної + з поточної `main`, щоб перевірка випуску та виправлення не блокували нову + розробку в `main` +- Якщо beta-тег уже було відправлено або опубліковано й він потребує виправлення, супроводжувачі створюють + наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега +- Докладна процедура випуску, погодження, облікові дані та примітки щодо відновлення + доступні лише супроводжувачам -## Попередня перевірка випуску +## Передвипускова перевірка -- Виконайте `pnpm check:test-types` перед попередньою перевіркою випуску, щоб тестовий TypeScript лишався - охопленим поза швидшим локальним бар’єром `pnpm check` -- Виконайте `pnpm check:architecture` перед попередньою перевіркою випуску, щоб ширші перевірки - циклів імпорту та меж архітектури були успішними поза швидшим локальним бар’єром -- Виконайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - артефакти випуску `dist/*` і bundle Control UI існували для кроку - перевірки pack -- Виконуйте `pnpm release:check` перед кожним тегованим випуском +- Запустіть `pnpm check:test-types` перед передвипусковою перевіркою, щоб + тестовий TypeScript лишався покритим поза швидшим локальним бар’єром `pnpm check` +- Запустіть `pnpm check:architecture` перед передвипусковою перевіркою, щоб + ширші перевірки циклів імпорту та меж архітектури були успішними поза швидшим локальним бар’єром +- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб + очікувані артефакти випуску `dist/*` і зібраний пакет Control UI були наявні для + кроку перевірки pack +- Запускайте `pnpm release:check` перед кожним тегованим випуском - Перевірки випуску тепер виконуються в окремому ручному workflow: `OpenClaw Release Checks` - Крос-ОС перевірка встановлення та оновлення під час виконання запускається з - приватного caller workflow + приватного workflow-джерела виклику `openclaw/releases-private/.github/workflows/openclaw-cross-os-release-checks.yml`, який викликає повторно використовуваний публічний workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Цей поділ навмисний: він зберігає справжній шлях випуску npm коротким, - детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються - у власному каналі, щоб не затримувати і не блокувати публікацію -- Перевірки випуску мають запускатися з посилання workflow `main`, щоб - логіка workflow і секрети лишалися канонічними -- Цей workflow приймає або наявний тег випуску, або поточний повний - 40-символьний SHA коміту `main` -- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; використовуйте - тег випуску для старіших комітів випуску -- Попередня перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний - повний 40-символьний SHA коміту `main` без вимоги вже запушеного тега -- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації -- У режимі SHA workflow синтезує `v` лише для перевірки метаданих - package; реальна публікація все одно потребує реального тега випуску -- Обидва workflow зберігають реальний шлях публікації та підвищення на GitHub-hosted - runners, тоді як немутувальний шлях валідації може використовувати більші - Blacksmith Linux runners +- Цей поділ навмисний: він зберігає реальний шлях npm-випуску коротким, + детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки працюють + у власній гілці, щоб не затримувати і не блокувати публікацію +- Перевірки випуску потрібно запускати з ref workflow `main` або з ref workflow + `release/YYYY.M.D`, щоб логіка workflow і секрети залишалися під контролем +- Цей workflow приймає або наявний тег випуску, або поточний повний 40-символьний SHA коміту гілки workflow +- У режимі SHA коміту він приймає лише поточний HEAD гілки workflow; для старіших комітів випуску + використовуйте тег випуску +- Передвипускова перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту гілки workflow без вимоги вже відправленого тега +- Цей шлях через SHA призначений лише для валідації і не може бути просунутий до реальної публікації +- У режимі SHA workflow синтезує `v` лише для перевірки + метаданих пакета; реальна публікація все одно потребує реального тега випуску +- Обидва workflow зберігають реальний шлях публікації та просування на GitHub-hosted + runners, тоді як незмінюваний шлях валідації може використовувати більші + Linux runners Blacksmith - Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` - з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` -- Попередня перевірка випуску npm більше не чекає на окремий канал перевірок випуску -- Виконайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний тег beta/виправлення) перед затвердженням -- Після публікації в npm виконайте + використовуючи секрети workflow `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- Передвипускова перевірка npm-випуску більше не чекає на окрему гілку перевірок випуску +- Перед погодженням запустіть + `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` + (або відповідний beta/тег виправлення) +- Після публікації в npm запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну версію beta/виправлення), щоб перевірити опублікований шлях - встановлення з реєстру в новому тимчасовому prefix -- Автоматизація випусків супроводжувачів тепер використовує схему preflight-then-promote: + (або відповідну beta/версію виправлення), щоб перевірити опублікований шлях + встановлення з реєстру в новому тимчасовому префіксі +- Автоматизація випусків супроводжувачів тепер використовує схему передвипускової перевірки з подальшим просуванням: - реальна публікація в npm має пройти успішний npm `preflight_run_id` - - стабільні випуски npm за замовчуванням спрямовуються в `beta` - - стабільна публікація npm може явно націлюватися на `latest` через вхід workflow - - мутація npm dist-tag на основі токена тепер знаходиться в + - реальна публікація в npm має бути запущена з тієї самої гілки `main` або + `release/YYYY.M.D`, що й успішний запуск передвипускової перевірки + - stable npm-випуски за замовчуванням націлюються на `beta` + - stable npm-публікацію можна явно націлити на `latest` через вхідні дані workflow + - зміна npm dist-tag на основі токена тепер розміщена в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - з міркувань безпеки, тому що `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як - публічний репозиторій зберігає публікацію лише через OIDC + з міркувань безпеки, оскільки `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як + публічний репозиторій зберігає лише публікацію через OIDC - публічний `macOS Release` призначений лише для валідації - - реальна приватна публікація mac має пройти успішні приватні mac + - реальна приватна публікація для mac має пройти успішні приватні mac `preflight_run_id` і `validate_run_id` - - реальні шляхи публікації підвищують уже підготовлені артефакти замість повторного + - реальні шляхи публікації просувають підготовлені артефакти замість повторного їх збирання -- Для стабільних випусків виправлень на кшталт `YYYY.M.D-N` постпублікаційний верифікатор - також перевіряє той самий шлях оновлення через тимчасовий prefix з `YYYY.M.D` до `YYYY.M.D-N`, - щоб стабільні виправлення не могли непомітно залишати старі глобальні встановлення на - базовому стабільному payload -- Попередня перевірка випуску npm завершується з помилкою за замовчуванням, якщо tarball не містить і - `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, - щоб ми знову не випустили порожню панель браузера -- `pnpm test:install:smoke` також примусово застосовує бюджет npm pack `unpackedSize` до +- Для stable-випусків із виправленнями, таких як `YYYY.M.D-N`, постпублікаційний верифікатор + також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`, + щоб виправлення випуску не могли непомітно залишити старіші глобальні встановлення на + базовому stable-пакеті +- Передвипускова перевірка npm-випуску завершується з помилкою за замовчуванням, якщо tarball не містить і + `dist/control-ui/index.html`, і непорожній вміст `dist/control-ui/assets/`, + щоб ми знову не випустили порожню браузерну панель керування +- `pnpm test:install:smoke` також примусово перевіряє бюджет `unpackedSize` npm pack на tarball кандидата на оновлення, щоб e2e перевірка інсталятора виявляла випадкове роздуття pack до шляху публікації випуску -- Якщо робота над випуском торкалася планування CI, маніфестів часу extension або - матриць тестів extension, перед затвердженням заново згенеруйте та перегляньте - виходи матриці workflow `checks-node-extensions`, якими керує planner, з `.github/workflows/ci.yml`, +- Якщо робота над випуском зачепила планування CI, маніфести часу виконання extension або + матриці тестів extension, перед погодженням згенеруйте повторно та перегляньте + виходи матриці workflow `checks-node-extensions`, якими володіє planner, із `.github/workflows/ci.yml`, щоб примітки до випуску не описували застарілу структуру CI -- Готовність стабільного випуску macOS також включає поверхні оновлювача: - - GitHub release має врешті містити запаковані `.zip`, `.dmg` і `.dSYM.zip` +- Готовність stable-випуску для macOS також охоплює поверхні оновлювача: + - GitHub-випуск має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - `appcast.xml` у `main` після публікації має вказувати на новий stable zip - - запакований застосунок має зберігати не-debug bundle id, непорожній Sparkle feed - URL і `CFBundleVersion`, не нижчий за канонічний мінімум Sparkle build + - запакований застосунок має зберігати bundle id не для debug, непорожній feed URL + для Sparkle та `CFBundleVersion` на рівні або вище канонічного мінімального build-рівня Sparkle для цієї версії випуску -## Вхідні параметри workflow NPM +## Вхідні дані workflow для NPM -`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри: +`OpenClaw NPM Release` приймає такі вхідні дані, керовані оператором: - `tag`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний SHA коміту `main` для попередньої перевірки лише з валідацією + повний 40-символьний SHA коміту гілки workflow для передвипускової перевірки лише для валідації - `preflight_only`: `true` для лише валідації/збирання/пакування, `false` для реального шляху публікації - `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав - підготовлений tarball з успішного запуску попередньої перевірки -- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta` + підготовлений tarball з успішного запуску передвипускової перевірки +- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta` -`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри: +`OpenClaw Release Checks` приймає такі вхідні дані, керовані оператором: - `ref`: наявний тег випуску або поточний повний 40-символьний SHA коміту `main` - для валідації + для перевірки під час запуску з `main`; з гілки випуску використовуйте + наявний тег випуску або поточний повний 40-символьний SHA коміту гілки випуску Правила: -- Stable і correction теги можуть публікуватися або в `beta`, або в `latest` -- Теги beta prerelease можуть публікуватися лише в `beta` -- Повний SHA коміту дозволений лише коли `preflight_only=true` -- Режим SHA коміту для перевірок випуску також вимагає поточний HEAD `origin/main` -- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час попередньої перевірки; +- Stable-теги та теги виправлень можуть публікуватися або в `beta`, або в `latest` +- Beta-теги попередніх випусків можуть публікуватися лише в `beta` +- Для `OpenClaw NPM Release` повний вхідний SHA коміту дозволений лише коли + `preflight_only=true` +- `OpenClaw Release Checks` завжди призначений лише для валідації та також приймає + поточний SHA коміту гілки workflow +- Режим SHA коміту для перевірок випуску також потребує поточного HEAD гілки workflow +- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час передвипускової перевірки; workflow перевіряє ці метадані перед продовженням публікації -## Послідовність стабільного випуску npm +## Послідовність stable npm-випуску -Під час створення стабільного випуску npm: +Під час створення stable npm-випуску: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - Поки тег ще не існує, ви можете використати поточний повний SHA коміту `main` для - dry run попередньої перевірки workflow лише з валідацією -2. Оберіть `npm_dist_tag=beta` для звичайного beta-first потоку, або `latest` лише - якщо ви навмисно хочете пряму стабільну публікацію -3. Запустіть `OpenClaw Release Checks` окремо з тим самим тегом або - повним поточним SHA `main`, коли вам потрібне live-покриття prompt cache - - Це навмисно окремо, щоб live-покриття лишалося доступним без - повторного зв’язування довгих або нестабільних перевірок із workflow публікації + - До появи тега ви можете використати поточний повний SHA коміту гілки workflow + для dry run передвипускового workflow лише для валідації +2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише + коли ви навмисно хочете пряму stable-публікацію +3. Окремо запустіть `OpenClaw Release Checks` з тим самим тегом або + повним поточним SHA коміту гілки workflow, коли вам потрібне live-покриття + перевірки кешу підказок + - Це навмисно винесено окремо, щоб live-покриття лишалося доступним без + повторного зчеплення довготривалих або нестабільних перевірок із workflow публікації 4. Збережіть успішний `preflight_run_id` -5. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим +5. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id` 6. Якщо випуск потрапив у `beta`, використайте приватний workflow - `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, - щоб підвищити цю стабільну версію з `beta` до `latest` -7. Якщо випуск навмисно було одразу опубліковано в `latest` і `beta` - має відразу слідувати за тією самою стабільною збіркою, використайте той самий приватний - workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його плановій - самовідновлювальній синхронізації перемістити `beta` пізніше + `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` + для просування цієї stable-версії з `beta` до `latest` +7. Якщо випуск навмисно було відразу опубліковано в `latest`, а `beta` + має одразу вказувати на ту саму stable-збірку, використайте той самий приватний + workflow, щоб направити обидва dist-tags на stable-версію, або дозвольте його + запланованій самовідновній синхронізації перемістити `beta` пізніше -Мутація dist-tag живе в приватному репозиторії з міркувань безпеки, тому що вона все ще -потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. +Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, оскільки вона все ще +потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає лише публікацію через OIDC. -Це робить як шлях прямої публікації, так і шлях beta-first promotion -задокументованими та видимими для операторів. +Це зберігає як шлях прямої публікації, так і шлях beta-first просування +задокументованими та видимими для оператора. ## Публічні посилання @@ -186,6 +201,6 @@ OpenClaw має три публічні канали випусків: - [`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) -Супроводжувачі використовують приватну документацію щодо випусків у +Супроводжувачі використовують приватну документацію випусків у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) як фактичний runbook.