Версии: LTS и STS

Salt с релизов «трёхтысячных» использует простую схему нумерации: мажорный номер — это целое число, например, 3006, 3007 или 3008, а точечные релизы (3008.1, 3008.2) содержат только исправления. Помимо этого, существует модель каналов поддержки: LTS (long-term support) для длительной эксплуатации и STS (short-term support) для короткоживущих веток с новыми возможностями. В 2026 году 3006.x — это старый LTS, переходящий в фазу critical-support, 3007.x — STS, а 3008 — новый LTS. Понимание этой модели важно, так как выбор ветки влияет на частоту обновлений, доступные модули и источники пакетов. Например, репозиторий packages.broadcom.com не содержит версий старше 3006.

Как это работает

LTS-ветка живёт долго и получает точечные релизы с исправлениями, на ней строят продакшен. STS-ветка выходит между LTS-релизами, принося новые функции, но сопровождается короче — с неё нужно быть готовым перейти на следующий LTS. Предыдущий LTS после выхода нового переходит в режим critical-support, где выпускаются только критические исправления, что подразумевает плановую миграцию. Важная веха — релиз 3008 и «Great Module Migration»: значительная часть модулей вынесена из ядра в community-расширения (GitHub-организация salt-extensions) и устанавливается отдельно командой salt-pip install saltext-…. Поэтому переход 3006 → 3008 включает не только смену пакетов, но и инвентаризацию используемых модулей. Порядок обновления в кластере строгий: сначала мастер, затем миньоны — мастер не должен быть старее миньонов.

Когда применять

Для продакшена выбирайте актуальный LTS — сейчас это 3008: длинное окно поддержки, предсказуемые точечные релизы и максимум внимания сообщества. STS (3007.x) оправдан, если нужна конкретная новая функциональность и есть ресурс на более частые миграции — например, на стендах, где обкатываются будущие изменения. Если парк всё ещё на 3006.x, статус critical-support означает, что миграция на 3008 — задача ближайшего планирования. Полезная практика — обкатывать новый мажор на staging-контуре с реальными состояниями и списком модулей: именно там всплывают переехавшие в saltext-… зависимости. Фиксируйте мажорную ветку в конфигурации репозитория, чтобы плановое обновление пакетов не превратилось во внеплановый переход на новый мажор.

Типичные ошибки

Самая дорогая ошибка — обновить миньоны раньше мастера: новые миньоны со старым мастером — неподдерживаемая комбинация, и проблемы проявляются самым непредсказуемым образом. Вторая ошибка — считать переход 3006 → 3008 «обычным апдейтом» и не проверить модули: после Great Module Migration часть состояний упадёт с ошибкой отсутствующего модуля, пока не доставите нужные расширения через salt-pip. Третья ошибка — надежда достать старые пакеты: версий старше 3006 в packages.broadcom.com нет, так что «заморозиться на древней версии» не получится — план миграции нужен в любом случае. Четвёртая ошибка — жить на STS без плана съезда: ветка коротко сопровождается, и её конец наступает быстрее, чем кажется.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы

🔤 Английские термины в этой теме