# Как выпускать релиз

## Подготовка через PR

1. Поднять версию согласованно в шести файлах:
   - `Cargo.toml` — версия пакета `tglock`;
   - `Cargo.lock` — версия только пакета `tglock`, без обновления зависимостей;
   - `tauri.conf.json` — версия приложения и имён установщиков;
   - `package.json` — версия frontend-пакета;
   - `package-lock.json` — верхняя версия и `packages[""].version`;
   - `ui/main.ts` — версия копируемого диагностического отчёта.
2. Подготовить описание изменений и проверок, отдельно указав экспериментальные
   платформы и непроверенные сценарии. Android получает `versionName`/`versionCode`
   из конфигурации Tauri при сборке; сгенерированный `tauri.properties` не коммитится.
3. Проверить финальные изменения PR и слить его в `main` с соблюдением обязательных
   проверок ветки. Дождаться зелёных проверок и Android workflow на итоговом HEAD
   `main` до создания тега. APK предыдущего PR-коммита не заменяет артефакт этого
   коммита: `headSha` Android run должен совпадать с коммитом будущего тега.

## Тег и сборка

Release workflow этого репозитория допускает тег только на текущем HEAD ветки
по умолчанию. Guard сохраняет прежнюю защиту от выпуска другого коммита:
ранее расхождение тега и `main` сопровождалось ошибкой публикации
`Resource not accessible by integration`.

1. Сверить `git ls-remote origin refs/heads/main` и локальный
   `git rev-parse HEAD` после перехода на финальный коммит `main`.
2. Убедиться, что выбранная версия и тег ещё не существуют, затем поставить
   аннотированный тег на этот коммит:

   ```bash
   git tag -a v2.0.0-beta.N -m "TGLock 2.0.0-beta.N"
   git push origin v2.0.0-beta.N
   ```

3. Пока релиз собирается, не добавлять коммиты в `main`. Guard проверяет HEAD
   в начале работы и не устраняет гонку после проверки.
4. Дождаться **всех** jobs Release. Workflow создаёт **draft** и сохраняет его
   черновиком при загрузке GUI, CLI и ARM64. Частично загруженный выпуск не должен
   становиться общедоступным до проверок.

Ручной `workflow_dispatch` запускайте на релизном теге, а не на ветке: часть
загрузчиков использует `github.ref_name` как имя релиза.

## Проверка артефактов и публикация

Зелёный workflow сам по себе недостаточен. В бетах 2 и 3 в GUI-бандл попадал
headless-бинарь, поэтому проверяются содержимое и происхождение:

- Windows: GUI `.exe` и `tglock-cli-x86_64-pc-windows-msvc.exe`.
- macOS: универсальные `.dmg`, `.app.tar.gz` и CLI.
- Linux x64: `.AppImage`, `.deb` и CLI.
- ARM64 Linux: `tglock-cli-aarch64-unknown-linux-musl` и его `.sha256`;
  workflow проверяет ELF без динамических зависимостей и запуск бинаря.
- Android: скачать ARM64 debug APK из успешного Android run с `headSha`,
  совпадающим с коммитом тега. Сохранить имя с версией и явной пометкой
  `android-arm64-debug`, прикрепить APK к тому же draft. Указать экспериментальный
  статус и ограничения debug-подписи из [ANDROID.md](ANDROID.md).

Пример проверки скачанного macOS-бандла:

```bash
gh release download vX.Y.Z --repo by-sonic/tglock -p 'TGLock_universal.app.tar.gz' -D /tmp/check
tar -xzf /tmp/check/TGLock_universal.app.tar.gz -C /tmp/check
python scripts/verify_bundle_binary.py /tmp/check/TGLock.app/Contents/MacOS/tglock
```

Проверьте версию скачанного CLI и хотя бы один реальный протокольный обмен
через него по [LIVE_PROBE.md](LIVE_PROBE.md). Зафиксируйте, какие платформы
исполнены локально, а какие проверены CI. Секрет локального прокси в заметки и
публичные артефакты не включается.

Когда набор файлов полон, подписи/контрольные суммы и версии сверены, а release
notes готовы, опубликуйте draft. Например:

```bash
gh release edit vX.Y.Z --repo by-sonic/tglock --draft=false --notes-file release-notes.md
```

Исторически `v2.0.0-beta.*` в этом репозитории публикуются с `prerelease=false`;
workflow сохраняет эту настройку. После публикации проверьте публичную страницу
релиза, ссылки скачивания и список файлов. Краткий пост об обновлении должен
ссылаться на опубликованный релиз и отделять проверенные исправления от
экспериментальных платформ.

## Если сборка или публикация упала

Сначала прочитайте ошибку и сверяйте коммит тега, `main`, workflow run и версии.
Не делайте вывод о причине только из текста `Resource not accessible by
integration`: он может относиться и к правам токена.

```bash
git ls-remote origin refs/heads/main 'refs/tags/vX.Y.Z^{}'
```

Если это ошибка инфраструктуры, повторите упавшие jobs на том же коммите.
Если нужна правка исходников, внесите её через PR и выберите новую версию для
нового тега. Опубликованные теги и бинарные артефакты не заменяйте: пользователи
должны иметь возможность воспроизвести уже выпущенную версию.