# Випуск релізів Oleafly

Зберіть повну чернетку з тегу версії, перегляньте кожен артефакт платформи, а потім опублікуйте через захищений робочий процес випуску.

Релізи Oleafly мають дві свідомі стадії. Тег версії збирає й перевіряє чернетку. Супровідник публікує ту саму чернетку окремим запуском робочого процесу.

Надсилання в `main` запускає CI, але не створює релізу.

## Зберіть чернетку

Почніть зі свіжої гілки `main` із зеленим CI.

```sh
git switch main
git pull --ff-only
./scripts/bump-version.sh 0.3.6
git commit -am "chore: release v0.3.6"
git push origin main
git tag v0.3.6
git push origin v0.3.6
```

Тег запускає `.github/workflows/release.yml`. Він збирає для таких цілей:

| Ціль | Інсталятори |
|---|---|
| macOS Apple Silicon | `.dmg` |
| Windows x64 | `.msi` і `-setup.exe` |
| Linux x64 | `.AppImage` і `.deb` |
| Linux ARM64 | `.AppImage` і `.deb` |

Кожна ціль завантажує й перевіряє свої закріплені sidecar-компілятори. Далі робочий процес зливає всі чотири фрагменти каналу оновлення в один `latest.json`. Чернетка вважається готовою, лише коли на місці кожен потрібний інсталятор і кожен запис оновлення.

## Перегляньте чернетку

Відкрийте чернетку на [сторінці GitHub Releases](https://github.com/Oleafly/Oleafly/releases). Перевірте нотатки релізу, імена інсталяторів, контрольні суми, підписи та `latest.json`. Не публікуйте неповну чернетку.

## Опублікуйте

Відкрийте **Actions → Release → Run workflow**. Уведіть той самий тег і оберіть **Publish the release**.

Запуск публікації повторює збірку та перевірки артефактів. Він також виконує живі контрактні тести проти Anthropic і Google, використовуючи кандидата в реліз. Підсумкове завдання відмовляється публікувати, якщо немає кожної підтримуваної платформи й повного каналу оновлення.

Публікація робить `latest.json` видимим для встановлених застосунків. Ставтеся до цього як до незворотної дії в продакшені. Якщо запуск публікації зазнає невдачі, лишіть реліз чернеткою, виправте причину й запустіть його знову.

## Номери версій

Oleafly дотримується семантичного версіонування:

- **Патчова**, як-от від `0.3.5` до `0.3.6`, для сумісних виправлень.
- **Мінорна**, як-от від `0.3.5` до `0.4.0`, для сумісних можливостей.
- **Мажорна**, як-от від `0.3.5` до `1.0.0`, для несумісних змін або першого стабільного релізу.

## Важливі перевірки

- Тег має збігатися з `package.json`, `src-tauri/tauri.conf.json`, `src-tauri/Cargo.toml` і `src-tauri/Cargo.lock`. Використовуйте `scripts/bump-version.sh` замість того, щоб редагувати їх окремо.
- Нотатки релізу беруться з відповідного розділу версії в `CHANGELOG.md`.
- Не використовуйте повторно опублікований тег. Для невдалої чернетки виправте гілку й створіть нову версію, якщо немає ясної причини замінити неопублікований тег.
- Підписування й нотаризація macOS використовують релізні секрети Apple. Windows Authenticode використовує Azure Artifact Signing, коли його секрети налаштовано. Підписи оновлення використовують окремий ключ підписування Tauri.

Див. [Автооновлення](/docs/engineering/updates/) щодо підписування оновлень і поведінки відкату. Інструкції з встановлення для користувачів — у розділі [Завантаження та встановлення](/docs/install/).