Версии: 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 без плана съезда: ветка коротко сопровождается, и её конец наступает быстрее, чем кажется.

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

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

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

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

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