chore(i18n): refresh uk translations

2026-04-14 21:24:01 +00:00 · 2026-04-14 21:24:01 +00:00 · 40d50faa5c
commit 40d50faa5c
parent 781f46041f
1 changed files with 102 additions and 96 deletions
--- a/docs/uk/reference/RELEASING.md
+++ b/docs/uk/reference/RELEASING.md
@ -1,181 +1,187 @@
 ---
 read_when:
-    - Шукаю визначення публічних каналів випуску
-    - Шукаю найменування версій і частоту випусків
-summary: Публічні канали випуску, найменування версій і частота випусків
+    - Шукаю визначення публічних каналів релізів
+    - Шукаю назви версій і частоту випусків
+summary: Публічні канали релізів, назви версій і частота випусків
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-04-14T16:20:31Z"
+    generated_at: "2026-04-14T21:23:21Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 021ae4b3e6a258c8396eccb99f00ca6cc268c2496258786521a053ebd776ba60
+    source_hash: 88724307269ab783a9fbf8a0540fea198d8a3add68457f4e64d5707114fa518c
    source_path: reference/RELEASING.md
    workflow: 15
 ---

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

-OpenClaw має три публічні канали випусків:
+OpenClaw має три публічні гілки випусків:

 - stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
 - beta: prerelease-теги, які публікуються в npm `beta`
- dev: рухома вершина `main`
+- dev: рухома голова `main`

-## Найменування версій
+## Назви версій

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

 ## Частота випусків

 - Випуски спочатку проходять через beta
- Stable з’являється лише після перевірки останньої beta
- Детальна процедура випуску, погодження, облікові дані та примітки щодо відновлення
-  доступні лише мейнтейнерам
+- Stable виходить лише після перевірки останньої beta
+- Детальна процедура випуску, затвердження, облікові дані та примітки щодо відновлення
+  доступні лише для супроводжувачів

 ## Передрелізна перевірка

- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб для кроку
-  перевірки pack були наявні очікувані артефакти випуску `dist/*` і збірка Control UI
+- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
+  артефакти випуску `dist/*` і збірка Control UI були наявні для кроку
+  перевірки pack
 - Запускайте `pnpm release:check` перед кожним тегованим випуском
- Перевірки випуску тепер запускаються в окремому ручному workflow:
+- Перевірки випуску тепер виконуються в окремому ручному workflow:
  `OpenClaw Release Checks`
- Цей поділ є навмисним: він зберігає реальний шлях npm-випуску коротким,
-  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки
-  залишаються у власному каналі, щоб не затримувати й не блокувати публікацію
- Перевірки випуску мають запускатися з workflow ref `main`, щоб логіка
+- Кросплатформова перевірка встановлення, оновлення та виконання під час роботи dispatch-иться з
+  приватного caller workflow
+  `openclaw/releases-private/.github/workflows/openclaw-cross-os-release-checks.yml`,
+  який викликає повторно використовуваний публічний workflow
+  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- Цей поділ навмисний: зберігайте реальний шлях npm-випуску коротким,
+  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у
+  власній гілці, щоб не затримувати і не блокувати публікацію
+- Перевірки випуску мають dispatch-итися з workflow ref `main`, щоб логіка
  workflow і секрети залишалися канонічними
 - Цей workflow приймає або наявний тег випуску, або поточний повний
  40-символьний SHA коміту `main`
- У режимі commit-SHA він приймає лише поточний HEAD `origin/main`; для
-  старіших комітів випуску використовуйте тег випуску
- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає
-  поточний повний 40-символьний SHA коміту `main` без вимоги наявності
-  запушеного тега
- Цей шлях SHA є лише для валідації й не може бути просунутий у реальну публікацію
- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
-  метаданих пакета; реальна публікація все одно вимагає реального тега випуску
- Обидва workflow залишають реальний шлях публікації й просування на
-  GitHub-hosted runners, тоді як немутувальний шлях валідації може
-  використовувати більші Linux runners Blacksmith
+- У режимі commit-SHA він приймає лише поточний HEAD `origin/main`; використовуйте
+  тег випуску для старіших комітів випуску
+- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний SHA коміту `main` без вимоги наявності запушеного тега
+- Цей шлях із SHA призначений лише для валідації й не може бути підвищений до реальної публікації
+- У режимі SHA workflow синтезує `v<package.json version>` лише для
+  перевірки метаданих пакета; реальна публікація все одно вимагає справжнього тега випуску
+- Обидва workflow зберігають реальний шлях публікації та підвищення на 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_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/коригувальний тег)
+  з використанням секретів workflow `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- Передрелізна перевірка npm-випуску більше не очікує на окрему гілку перевірок випуску
+- Перед затвердженням запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
+  (або відповідний тег beta/correction)
 - Після публікації в npm запустіть
  `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/коригувальну версію), щоб перевірити шлях встановлення
-  опублікованого реєстру в новому тимчасовому prefix
- Автоматизація випусків мейнтейнерів тепер використовує підхід preflight-then-promote:
+  (або відповідну версію beta/correction), щоб перевірити опублікований шлях
+  встановлення з реєстру в новому тимчасовому префіксі
+- Автоматизація випусків для супроводжувачів тепер використовує схему preflight-then-promote:
  - реальна публікація в npm має пройти успішний npm `preflight_run_id`
-  - stable npm-випуски за замовчуванням націлені на `beta`
-  - stable npm-публікація може явно націлювати `latest` через вхід workflow
-  - мутація npm dist-tag на основі токена тепер знаходиться в
+  - стабільні npm-випуски за замовчуванням націлюються на `beta`
+  - стабільна npm-публікація може явно націлювати `latest` через вхід workflow
+  - мутація npm dist-tag на основі токена тепер розміщена в
    `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
    з міркувань безпеки, оскільки `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
-    публічний репозиторій зберігає публікацію лише через OIDC
+    публічний репозиторій зберігає OIDC-only публікацію
  - публічний `macOS Release` призначений лише для валідації
-  - реальна приватна mac-публікація має пройти успішні приватні mac
+  - реальна приватна публікація mac має пройти успішні приватні mac
    `preflight_run_id` і `validate_run_id`
-  - реальні шляхи публікації просувають підготовлені артефакти замість їх повторного збирання
- Для stable-коригувальних випусків на кшталт `YYYY.M.D-N` верифікатор після публікації
-  також перевіряє той самий шлях оновлення тимчасового prefix з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб коригування випусків не могли непомітно залишити старіші глобальні встановлення
-  на базовому stable-навантаженні
- Передрелізна перевірка npm завершується за принципом fail closed, якщо tarball не містить
-  і `dist/control-ui/index.html`, і непорожнє навантаження `dist/control-ui/assets/`,
-  щоб ми знову не випустили порожню панель браузера
- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до
-  tarball кандидата на оновлення, щоб installer e2e перехоплював випадкове
-  роздуття pack до шляху публікації випуску
- Якщо робота над випуском торкалася планування CI, маніфестів часу extension або
-  матриць тестів extension, перед погодженням повторно згенеруйте й перегляньте
-  workflow matrix outputs, що належать planner, для `checks-node-extensions` з `.github/workflows/ci.yml`,
-  щоб примітки до випуску не описували застарілу структуру CI
- Готовність stable macOS-випуску також включає поверхні оновлювача:
-  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` у `main` після публікації має вказувати на новий stable zip
-  - запакований app має зберігати не-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
+  - реальні шляхи публікації підвищують уже підготовлені артефакти замість повторної
+    їх збірки
+- Для стабільних виправлювальних випусків на кшталт `YYYY.M.D-N` post-publish verifier
+  також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб виправлення випуску не могли непомітно залишити старіші глобальні встановлення на
+  базовому стабільному payload
+- Передрелізна перевірка npm-випуску завершується fail closed, якщо tarball не містить і
+  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
+  щоб ми знову не випустили порожню інформаційну панель браузера
+- `pnpm test:install:smoke` також забезпечує бюджет `unpackedSize` npm pack для
+  tarball-кандидата на оновлення, щоб installer e2e виявляв випадкове роздуття пакета
+  до шляху публікації випуску
+- Якщо робота над випуском зачіпала планування CI, маніфести часу виконання розширень або
+  матриці тестів розширень, згенеруйте заново та перегляньте виходи матриці workflow
+  `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`
+  перед затвердженням, щоб примітки до випуску не описували застарілу структуру CI
+- Готовність стабільного випуску macOS також включає поверхні оновлювача:
+  - GitHub-випуск має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` у `main` після публікації має вказувати на новий стабільний zip
+  - запакований застосунок має зберігати не-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище канонічного мінімального build floor Sparkle
    для цієї версії випуску

 ## Входи 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` для передрелізної перевірки лише для валідації
- `preflight_only`: `true` для лише валідації/збирання/пакування, `false` для
+- `preflight_only`: `true` для лише валідації/збірки/пакування, `false` для
  реального шляху публікації
- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав
-  підготовлений tarball з успішного виконання передрелізної перевірки
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
+- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
+  підготовлений tarball з успішного запуску передрелізної перевірки
+- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`

-`OpenClaw Release Checks` приймає такі вхідні дані, керовані оператором:
+`OpenClaw Release Checks` приймає такі вхідні параметри, керовані оператором:

 - `ref`: наявний тег випуску або поточний повний 40-символьний commit
-  SHA `main` для перевірки
+  SHA `main` для валідації

 Правила:

 - Stable і correction-теги можуть публікуватися або в `beta`, або в `latest`
 - Beta prerelease-теги можуть публікуватися лише в `beta`
- Повний вхід commit SHA дозволений лише коли `preflight_only=true`
+- Повний commit SHA дозволений лише коли `preflight_only=true`
 - Режим commit-SHA для перевірок випуску також вимагає поточний HEAD `origin/main`
- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки;
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час передрелізної перевірки;
  workflow перевіряє ці метадані перед продовженням публікації

-## Послідовність stable npm-випуску
+## Послідовність стабільного npm-випуску

-Під час створення stable npm-випуску:
+Під час створення стабільного npm-випуску:

 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи тега ви можете використати поточний повний SHA коміту `main` для
+   - До появи тега ви можете використовувати поточний повний SHA коміту `main` для
     dry run передрелізного workflow лише для валідації
-2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку або `latest` лише
-   коли ви навмисно хочете пряму stable-публікацію
+2. Оберіть `npm_dist_tag=beta` для звичайного beta-first потоку або `latest` лише
+   коли ви свідомо хочете прямої стабільної публікації
 3. Окремо запустіть `OpenClaw Release Checks` з тим самим тегом або
   повним поточним SHA `main`, якщо вам потрібне live-покриття prompt cache
-   - Це окремо навмисно, щоб live-покриття залишалося доступним без
-     повторного зв’язування довготривалих або нестабільних перевірок із workflow публікації
+   - Це навмисно винесено окремо, щоб live-покриття залишалося доступним без
+     повторного зв’язування довгих або нестабільних перевірок із workflow публікації
 4. Збережіть успішний `preflight_run_id`
 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`,
-   щоб просунути цю stable-версію з `beta` у `latest`
-7. Якщо випуск навмисно було опубліковано безпосередньо в `latest`, а `beta`
-   має одразу перейти на ту саму stable-збірку, використайте той самий приватний
-   workflow, щоб спрямувати обидва dist-tags на stable-версію, або дозвольте його запланованій
-   самовідновлювальній синхронізації перемістити `beta` пізніше
+   щоб підвищити цю стабільну версію з `beta` до `latest`
+7. Якщо випуск було навмисно опубліковано безпосередньо в `latest`, і `beta`
+   має одразу перейти на ту саму стабільну збірку, використайте той самий приватний
+   workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його
+   запланованій самовідновлюваній синхронізації перемістити `beta` пізніше

-Мутація dist-tag знаходиться в приватному репозиторії з міркувань безпеки, оскільки вона все ще
-потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
+Мутація dist-tag розміщена в приватному репозиторії з міркувань безпеки, оскільки вона все ще
+потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only публікацію.

-Це залишає і шлях прямої публікації, і шлях 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)
+- [`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-cross-os-release-checks-reusable.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)

-Мейнтейнери використовують приватну документацію з випусків у
+Супроводжувачі використовують приватну документацію щодо випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
 як фактичний runbook.