openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-21 04:35:50 +00:00
parent 4fb88df44f
commit 76660ac584
1 changed files with 123 additions and 108 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

231
docs/uk/reference/RELEASING.md
View File

@ -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.json version>` лише для перевірки метаданих
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<package.json version>` лише для перевірки
метаданих пакета; реальна публікація все одно потребує реального тега випуску
- Обидва 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.