Как устроена нумерация релизов 1C:ERP и почему фирма «1С» параллельно ведет несколько версий?

При сопровождении и планировании обновлений крупных корпоративных систем на базе 1С:ERP Управление предприятием специалисты часто сталкиваются с ситуацией, когда в графике релизов и на портале обновлений одновременно фигурируют несколько номеров с близкими индексами. Разберем детально, как устроена система версионирования в экосистеме 1С:Предприятие 8, почему возникает иллюзия параллельного сопровождения нескольких версий и как правильно планировать переход между ними.

Структура нумерации версий и конфигураций в «1С:Предприятие 8»

Для понимания жизненного цикла продукта рассмотрим стандарты разработки и нумерации конфигураций фирмы «1С». Номер каждого дистрибутива состоит из четырех разрядов, разделенных точками, в формате: {Р}.{П}.{В}.{С}.

1. Р (Номер редакции) — глобальная архитектурная версия продукта (например, 1, 2). Переход на новую редакцию означает фундаментальные изменения в архитектуре метаданных, структуре хранения регистров и ключевых механизмах учета.
2. П (Номер подредакции) — номер подверсии внутри глобальной редакции (например, 2.2, 2.4, 2.5). Для обозначения поколения конфигурации обычно используют комбинацию номера редакции и подредакции через точку.
3. В (Номер функциональной версии) — номер функционального релиза в рамках текущей подредакции (например, 2.4.1, 2.4.2, 2.4.3). В функциональные версии разработчики добавляют новые подсистемы, обновляют методики планирования, расширяют интеграционные библиотеки (ЕГАИС, маркировка, ЭДО).
4. С (Номер сборки / билда) — порядковый номер сборки конкретного релиза (например, 2.4.3.145). На этом уровне выпускаются исправления зарегистрированных ошибок, оперативные правки форм регламентированной отчетности и точечные обновления.

Проанализируем пример чтения номера конфигурации: в версии 2.4.2.139 число 2 — редакция, 4 — подредакция, 2 — номер функциональной версии, а 139 — номер финальной сборки.

Почему в планах выпуска отображаются сразу несколько версий

В графике выхода обновлений пользователи нередко видят несколько идущих подряд версий, например 2.4.2, 2.4.3 и 2.4.4. Выясним причину такого отображения и структуру конвейерной разработки фирмы «1С»:

1. Текущая рабочая версия (например, 2.4.2) — стабильный релиз, на котором предприятия ведут учет. Для него выпускаются сборки с исправлением выявленных ошибок и поддержкой изменений текущего законодательства.
2. Тестируемая версия (например, 2.4.3) — релиз, в который уже заложены крупные новшества (например, поддержка формата УТМ 3.0 для ЕГАИС или помарочного учета алкогольной продукции). Данная версия выкладывается в статусе тестовой для партнеров и пользователей, чтобы провести обкатку функционала на реальных базах до выхода официального финального статуса.
3. Перспективная версия (например, 2.4.4) — релиз, находящийся в активной внутренней разработке методистов и программистов «1С». На портале публикуется состав планируемых изменений, чтобы технические команды на стороне клиентов могли заранее оценить влияние будущих переработок на свои доработанные механизмы.

Важно подчеркнуть: фирма «1С» не поддерживает несколько функциональных версий внутри одной ветки одновременно на постоянной основе. Как только версия 2.4.3 переходит в статус финальной рабочей версии, выпуск сборок для ветки 2.4.2 прекращается. Все последующие обновления законодательства и исправления ошибок выходят уже исключительно на базе 2.4.3.

Почему новые интеграции и функции не встраиваются в старые сборки

Рассмотрим частый вопрос: почему при выходе критических изменений в законодательстве (например, переход на новый формат обмена с контролирующими органами или обновление универсального транспортного модуля) разработчики не добавляют исправление в текущую сборку, а требуют перехода на следующую версию?

Крупные изменения законодательства (в частности, помарочный учет ЕГАИС, новые механизмы НДС, прослеживаемость) затрагивают ядро конфигурации — типовые регистры накопления, структуру табличных частей документов движения запасов и алгоритмы проведения. Внедрение таких изменений в старый релиз в виде простого патча технически невозможно, так как это нарушит совместимость и целостность базы данных. Поэтому изменения интегрируются в состав очередной функциональной версии, требующей регламентного обновления метаданных и обработчиков обновления информационной базы.

Определение версии конфигурации программным способом

Для автоматизации процедур контроля релизов и проверки совместимости модулей расширений разберем, как программно получить номер текущей конфигурации в кодовой базе «1С:Предприятие 8»:

// Получение полной строки версии текущей конфигурации
ПолнаяВерсия = Метаданные.Версия;

// Разбор структуры номера на составляющие разряды
МассивПодстрок = СтрРазделить(ПолнаяВерсия, ".");
Если МассивПодстрок.Количество() = 4 Тогда
    НомерРедакции      = Число(МассивПодстрок[0]);
    НомерПодредакции   = Число(МассивПодстрок[1]);
    НомерВерсии        = Число(МассивПодстрок[2]);
    НомерСборки        = Число(МассивПодстрок[3]);
    
    // Проверка соответствия минимальным системным требованиям
    Если НомерРедакции = 2 И НомерПодредакции = 4 И НомерВерсии >= 3 Тогда
        // Доступны механизмы обмена по новым протоколам
        ИспользоватьНовыйФорматОбмена = Истина;
    Иначе
        ИспользоватьНовыйФорматОбмена = Ложь;
    КонецЕсли;
КонецЕсли;

Стратегия планирования обновлений на крупных проектах

Проанализируем правильный алгоритм действий для проектной команды при выходе новых версий конфигурации 1С:ERP:

1. Анализ состава изменений релиза. Изучаем сопроводительный файл ReadMe.txt и документацию к обновлению на предмет изменений в структурах регистров и процедур проведения, которые могли быть переопределены в расширениях или кастомизированном коде.
2. Тестирование на копии рабочей базы. Выполняем предварительное накатывание релиза на копию базы данных, замеряем время выполнения длительных обработчиков обновления информационной базы (регламентное задание ВыполнитьОбновлениеИнформационнойБазы подсистемы СтандартныеПодсистемы).
3. Прямой переход через версию. Если на портале одновременно доступны текущая версия (например, 2.4.2) и свежая функциональная версия (например, 2.4.3), нет необходимости последовательно внедрять каждый промежуточный функциональный релиз в рабочую среду. Допускается выполнение цепочки обновления сразу до целевого актуального релиза в рамках одного технологического окна.
4. Проверка нетиповых доработок. Особое внимание уделяем блокам обособленного учета по направлениям деятельности и назначениям, структуре производства и регламентированного учета, так как эти разделы претерпевают наибольшие изменения при смене функциональных версий.