Совместимость и обновления

Поддерживаемая матрица версий, версионирование и подпись артефактов релиза, окно обновления и политика устаревания

Эта страница — контракт совместимости: с чем протестирован Omniflow, как идентифицируется и проверяется релиз, насколько устаревшей может быть установка перед обновлением, и как устаревшая возможность выводится из эксплуатации, а не удаляется молча.

​

Матрица совместимости

Компонент	Поддерживается	Примечания
Remnawave	3.2.x	Ориентирован на поверхность API 3.2.2; проверяется в internal/remnawave/contract_test.go.
PostgreSQL	18.x	Единственное долговременное хранилище. Поставляемые образы фиксируют соответствующие клиентские утилиты PostgreSQL 18 для pg_dump/pg_restore.
Valkey	9.x	Только кэш, ограничения частоты запросов, блокировки и одноразовое состояние — никогда источник истины.
Go	1.26	Только на этапе сборки. Нужен контрибьюторам, собирающим из исходников; поставляемые Docker-образы уже содержат скомпилированный бинарник.
Bun / Node.js	Bun 1.3, Node ≥ 26	Только на этапе сборки фронтенд-воркспейса. Не требуется для запуска поставляемого образа web.
Браузеры	browserslist defaults	Примерно последние 2 версии вечнозелёных Chrome, Firefox, Safari и Edge, плюс Firefox ESR; Internet Explorer исключён. Закреплено на этапе сборки в apps/web/package.json.

Go и Bun — требования для контрибьюторов, а не для операторов. Установка запускает образы, опубликованные в ghcr.io/kewldan/omniflow/*, и никогда не нуждается в тулчейне Go или Bun на хосте.

Эта таблица описывает, с чем протестирована и собрана текущая линия main. Будущий релиз 1.x, меняющий поддерживаемую версию, обновляет эту строку, а версия, прекращающая поддержку чего-то из этой таблицы, называется в CHANGELOG.md, а не убирается молча — см. раздел Политика устаревания.

​

Версионирование и артефакты релиза

Релизы следуют Semantic Versioning и собираются Release Please из Conventional Commits, который также формирует CHANGELOG.md — ничего не пишется вручную постфактум.

Каждый помеченный релиз публикует четыре мультиархитектурных (linux/amd64, linux/arm64) образа контейнеров в GitHub Container Registry:

ghcr.io/kewldan/omniflow/api:vX.Y.Z
ghcr.io/kewldan/omniflow/bot:vX.Y.Z
ghcr.io/kewldan/omniflow/worker:vX.Y.Z
ghcr.io/kewldan/omniflow/web:vX.Y.Z

Каждый образ также помечен тегом X.Y, чтобы развёртывание могло следовать минорной линии, не плавая на latest.

​

SBOM, происхождение сборки и подписи

К каждой сборке образа прикладываются SBOM и происхождение сборки в стиле SLSA (sbom: true и provenance: mode=max у docker/build-push-action), после чего образ подписывается бесключевым способом через cosign, используя собственную OIDC-идентичность релизного workflow в GitHub Actions — ключа подписи для хранения, ротации или утечки не существует. Подпись записывается в публичный журнал прозрачности Rekor.

Проверьте образ перед развёртыванием:

cosign verify \
  --certificate-identity-regexp 'https://github.com/kewldan/omniflow' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/kewldan/omniflow/api:vX.Y.Z

Изучите приложенный SBOM и происхождение сборки командой docker buildx imagetools inspect --format '{{ json .SBOM }}' ghcr.io/kewldan/omniflow/api:vX.Y.Z (и .Provenance для происхождения сборки).

​

Тестирование обновлений

Джоб migrations в CI доказывает каждый поддерживаемый путь обновления до мержа: он применяет схему от пустой базы через каждый префикс истории миграций до головной версии и подтверждает, что повторное применение головной версии — это отсутствие изменений. Именно это на практике означают «автоматические тесты обновления» — миграция, которая только компилируется, не проверена, поэтому это выполняется на реальном PostgreSQL при каждом изменении, а не только во время релиза.

Пошаговые процедуры обновления, отката и обновления мажорной версии PostgreSQL живут на странице Резервные копии, восстановление и аварийное восстановление, а не дублируются здесь.

​

Политика миграций и окно поддерживаемых обновлений

• Миграции применяются только вперёд. Omniflow не поставляет обратные миграции; откат схемы — это восстановление из резервной копии, снятой непосредственно перед обновлением, как описано в разделе Откат.
• Миграция никогда не редактируется после того, как вышла в релизе. Изменение схемы всегда выходит новой миграцией, а её контрольная сумма в database/migrations/atlas.sum формируется командой atlas migrate hash и никогда не редактируется вручную.
• Обновления применяются последовательно через выпущенные версии — окно поддерживаемых обновлений это именно то, что джоб migrations в CI проверяет как базовую линию: каждый префикс истории миграций до головной версии. Не существует поддерживаемого пути, пропускающего применение миграций промежуточного релиза; сервис migrate при каждом запуске стека применяет всё, что ещё не выполнено, по порядку.
• Повторное применение миграций всегда безопасно: Atlas помнит, что уже выполнено, и повторное применение — это отсутствие изменений.

​

Политика устаревания

Об устаревании объявляется до удаления, а удаление всегда оформляется записью в CHANGELOG.md — никогда молчаливым изменением поведения.

• API. Устаревшая операция или поле OpenAPI помечается deprecated: true в api/openapi.yaml и продолжает работать как минимум ещё один минорный релиз перед удалением.
• Переменные окружения. Устаревшая переменная продолжает работать, её замена документируется рядом с ней как минимум один минорный релиз, а её итоговое удаление называется в CHANGELOG.md, а не вызывает молчаливое изменение поведения при старте.
• Поведение базы данных. Изменение поведения сначала выходит аддитивно — новый столбец или таблица рядом со старыми — а не переписывает существующее поведение в том же релизе, который вводит замену. Сам переход, а не только конечная точка, — это отрецензированная миграция.
• Интеграции. Адаптер Remnawave или платёжного провайдера поддерживает версии, действительно покрытые его контрактными тестами, опубликованные в матрице совместимости выше. Прекращение поддержки версии — это запись в CHANGELOG.md, а не молчаливое изменение контрактного теста.

​

Связанные страницы

Развёртывание

Топология Compose, тома и образы, которые описывает эта матрица.

Резервные копии, восстановление и аварийное восстановление

Пошаговые процедуры обновления, отката и обновления мажорной версии PostgreSQL.