← На главную

Вопрос выбора и обновления платформы 1С:Предприятие 8.3 часто вызывает путаницу даже у опытных специалистов. Система нумерации 1С специфична, а параллельная поддержка нескольких веток разработки (например, 8.3.21, 8.3.22 и 8.3.23 одновременно) заставляет сомневаться: что важнее — номер версии или дата выпуска? В этой статье мы подробно разберем структуру номера версии, логику сравнения релизов и выясним, почему дата выхода иногда играет критическую роль при выборе платформы.

Структура номера версии платформы

Для начала проанализируем, что означают цифры в номере версии A.B.C.D (например, 8.3.22.1704):

1. 8.3 — это поколение (серия) платформы. На текущий момент это актуальное поколение, которое развивается уже много лет.
2. 22 — номер ветки (релиза). Каждая новая ветка (21, 22, 23 и т.д.) добавляет в платформу значительный новый функционал и изменения в ядре.
3. 1704 — номер сборки (билда). Показывает количество исправлений и мелких доработок внутри конкретной ветки.

Рассмотрим основной принцип сравнения: математическая логика превалирует над календарной. С точки зрения системы 1С и механизмов проверки требований конфигурации, версия 8.3.22.1704 всегда будет считаться "выше" и "новее", чем любая версия из ветки 8.3.21.XXXX, даже если билд 21-й ветки вышел на неделю позже календарно.

Почему новые даты выпуска появляются у старых веток?

Разберем ситуацию, которая часто сбивает с толку: выход версии 8.3.20.2184 от 16.11.22 и версии 8.3.22.1704 от 14.11.22. Почему старая ветка обновляется позже новой?

Это происходит из-за политики параллельной поддержки. Фирма "1С" одновременно поддерживает несколько актуальных веток (на текущий момент это обычно 3–4 последние ветки). Когда в коде платформы обнаруживается критическая ошибка или уязвимость, исправление ("патч") выпускается одновременно для всех поддерживаемых веток. Поэтому мы видим свежие даты выхода у "старых" веток 20 или 21. Однако это не делает их функционально более современными, чем ветка 22.

Критический фактор: инцидент 15.11.2022

Проанализируем, почему в обсуждениях специалистов так часто фигурируют даты середины ноября 2022 года. Это важный исторический контекст, который напрямую влияет на выбор версии платформы. 15 ноября 2022 года произошел глобальный сбой в системе лицензирования 1С: из-за программной ошибки в механизме защиты платформы работа тысяч серверов была заблокирована.

В связи с этим были экстренно выпущены релизы:

• Версии от 14.11.2022 (например, 8.3.22.1704) были первыми попытками исправить ситуацию, но они содержали ошибки.
• Версии от 16.11.2022 (например, 8.3.22.1709) и выше — это уже стабилизированные сборки, в которых проблема лицензирования была решена окончательно.

Поэтому, если перед нами стоит выбор между 8.3.22.1704 и 8.3.22.1709, мы обязательно выбираем более поздний билд, так как дата здесь указывает на исправление критического бага платформы.

Минимальные требования конфигурации и работа с "будущими" ветками

Выясним, как интерпретировать требования конфигураций (например, ЗУП 3.1 или БП 3.0). Если в требованиях указано: "Минимальная версия платформы 8.3.22.1704", это означает следующее:

1. Любая версия внутри 22-й ветки с билдом ниже 1704 (например, 1600) не подойдет.
2. Любая версия из более младших веток (21, 20, 19) не подойдет, даже если они вышли вчера.
3. Любая версия из старших веток (8.3.23.XXXX, 8.3.24.XXXX) подойдет, даже если они прямо не указаны в списке. Платформа 1С обладает обратной совместимостью снизу вверх.

Однако стоит учитывать стабильность. Новые ветки (например, только что вышедшая 24-я) могут содержать ошибки в новом функционале. Традиционно "золотым стандартом" считается использование платформы на одну ветку ниже самой последней доступной, если конфигурация не требует иного.

Особенности версий 1C:Fresh

Посмотрим на ситуацию с облачным сервисом "1С:Фреш". Часто пользователи замечают, что в облаке стоит версия (например, 8.3.22.2111), которой нет в публичном доступе для скачивания (доступна только 8.3.22.2106). Это нормальная практика.

Версии для "Фреша" — это зачастую стабилизационные сборки. Они проходят обкатку на огромных нагрузках облака. Иногда такие версии остаются внутренними для сервиса, а иногда публикуются для всех спустя 1–2 недели. Если ваша конфигурация требует версию "как во Фреше", а её нет в доступе — устанавливайте самый свежий доступный билд этой же ветки.

Можно ли обновлять платформу "прыжком"?

Разберем технический момент перехода со старых версий (например, с 8.3.19.XXXX) на 8.3.22.XXXX. В отличие от конфигураций, где нужно последовательно накатывать обновления, платформу можно обновлять "прыжком".

Вы можете удалить старую версию платформы и сразу установить актуальную. Никаких промежуточных шагов не требуется. Единственное правило: при первом запуске информационной базы под новой платформой необходимо обладать правами администратора, так как могут потребоваться обновления служебных структур данных базы (хотя для платформы это происходит редко, в основном это касается релиза конфигурации).

Итоговые рекомендации по выбору

Подводя итог, выделим алгоритм выбора версии:

1. Проверяем минимальные требования актуального релиза конфигурации в файле readme.txt или на портале техподдержки.
2. Смотрим на номер ветки. Если требуется 22-я ветка, не пытаемся использовать 21-ю, какой бы "свежей" по дате она ни была.
3. Внутри нужной ветки всегда выбираем самый высокий номер билда (последние 4 цифры).
4. Избегаем релизов, выпущенных в моменты "авральных" правок (как в случае с 14.11.2022), отдавая предпочтение версиям, вышедшим через несколько дней после крупных инцидентов.