Релиз

Один release GigaLoom связывает Python, npm, Git и embedded Web assets. Единственный hand-edited источник identity — release/version.toml; scripts/release.py генерирует и проверяет release/release.json и все ecosystem projections. Для первого стабильного Native Agent Gateway точная identity такова:

Поверхность	Identity
Canonical release	0.9.1
Git tag	v0.9.1
PyPI	gigaloom==0.9.1
npm	@gigaloom/web@0.9.1

Root Python metadata, npm metadata, generated manifest, skeleton changelog, package-documentation snippets и release/artifact-set.toml должны точно соответствовать canonical file. CI отклоняет ручное изменение projection.

Бамп версии

Из корня репозитория выполните одну hermetic source-to-projection операцию:

git switch -c release/0.8.0-alpha.1
./scripts/release bump 0.8.0-alpha.1

bump обновляет все version projections с rollback при ошибке процесса, затем проверяет результат, включая packaged product inventory. JSON receipt перечисляет точные изменённые пути и оставшиеся human/external gates. Команда не собирает artifact, не коммитит, не создаёт tag, ничего не публикует и не обращается к provider. Повторный запуск для той же версии — byte-identical no-op.

./scripts/release diff <version> показывает изменения без записи, а ./scripts/release show выводит canonical identity. Старый prepare остаётся совместимым. Отдельный verify сохраняется для CI и tag trust boundary; сразу после успешного bump он не нужен.

Политика тегов

Новые релизы используют только стандартный тег v<release>. Создавайте protected tag на точном проверенном commit из main. Tag запускает immutable candidate build; публикация начинается только после успешных build, parity, checksum, denylist и attestation gates. Workflows не создают, не двигают и не исправляют теги.

Исторические prefix-shaped tags остаются историей. Не используйте эти prefixes для новых releases. После принятия версии хотя бы одним registry tag нельзя перемещать или удалять. Ошибочный неопубликованный tag исправляется по audited repository policy, а не обходится workflow.

Checklist maintainer

1. Убедитесь, что назначенные backup owners GitHub и PyPI приняли доступ с 2FA согласно governance policy.
2. Выполните документированный bump, заполните оба generated changelog skeleton и проверьте точные changed paths из receipt.
3. Соберите frontend assets и выполните полный non-live quality gate.
4. Убедитесь, что release commit находится в main, а документированные main/tag rulesets активны.
5. Убедитесь, что Trusted Publishers PyPI и npm указывают точные project/package, repository, publish workflow и environment release-production, а environment не требует reviewer approval.
6. Создайте protected standard tag на этом source SHA. Tag автоматически строит и аттестует candidate, затем после успеха запускает publication из того же workflow run.
7. Следите за candidate, registry checks и GitHub Release. Зафиксируйте candidate run ID, полный source SHA и SHA-256 файла candidate-manifest.json для recovery.

Двухфазный workflow

.github/workflows/publish-pypi.yml запускается push защищённого v* tag, строит и аттестует один retained candidate, но не публикует registry packages или GitHub Release.

.github/workflows/release-publish.yml — отдельный workflow под environment release-production. Успешное завершение candidate запускает его через workflow_run; resolver использует точный triggering run ID и требует один непросроченный SHA-bound artifact. Protected job повторно проверяет tag, ancestry, metadata, checksums, byte parity и legacy denylist и ничего не пересобирает. Перед initial publication или recovery отсутствующего registry он также требует, чтобы точный GitHub Release tag был свободен. После доказательства точных bytes в обоих registry финальная граница принимает либо свободный tag, либо один mutable exact-tag Release без загруженных assets. Такой Release принимается без перезаписи assets, а metadata release channel нормализуется. Manual dispatch остаётся только для recovery и требует run ID, полный SHA, tag, manifest digest и recovery mode.

Выберите ровно один mode:

• initial: обе версии отсутствуют; опубликовать npm с provenance, затем PyPI;
• recover-pypi: точные npm bytes существуют, PyPI отсутствует; публиковать только PyPI;
• recover-npm: точные PyPI files существуют, npm отсутствует; публиковать только npm;
• release-assets-only: оба registry содержат точные candidate bytes; не публиковать packages и создать GitHub Release последним либо принять один пустой mutable exact-tag Release без перезаписи assets.

Любой неожиданный filename или digest, malformed registry response либо outage останавливает workflow. Registry, где операция уже завершилась, при recovery повторно не публикуется. Заранее созданный GitHub Release останавливает workflow до записи в любой registry. Только после доказательства точных registry bytes явный release-assets-only recovery может принять его, и лишь если exact-tag Release mutable и не содержит загруженных assets; любая коллизия или immutable граница завершается fail-closed.

Rollback и recovery

До принятия версии registry можно откатить release automation или source и построить новый candidate из нового commit. После успеха npm или PyPI version и tag неизменяемы. Для завершения отсутствующего registry используйте только точный retained candidate либо увеличьте все release identities и выпустите новую версию. Нельзя пересобирать partial release, перезаписывать package files или перемещать tag.

Trusted Publisher, tags, GitHub releases и package publication — отдельные внешние мутации. См. runbook восстановления.