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

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

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

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

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

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

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 (відкривається в новій вкладці). Перевірте нотатки релізу, імена інсталяторів, контрольні суми, підписи та 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.

Див. Автооновлення щодо підписування оновлень і поведінки відкату. Інструкції з встановлення для користувачів — у розділі Завантаження та встановлення.