Многие пользователи программ 1С сталкиваются с ситуацией, когда номера обновлений идут не по порядку. Например, после установки релиза 3.0.150.29 для "1С:Бухгалтерии" следующей доступной версией оказывается 3.0.150.33. Возникает логичный вопрос: а куда делись версии с 30-й по 32-ю? Это не ошибка и не сбой в системе нумерации. Давайте вместе проанализируем ситуацию и выясним, почему так происходит.
Ответ кроется в сложном внутреннем процессе разработки, тестирования и выпуска программных продуктов в фирме "1С". Те номера версий, которые мы видим в списке доступных обновлений, — это лишь верхушка айсберга, успешно прошедшая все этапы контроля качества.
Процесс разработки любого обновления — это непрерывная работа. Программисты вносят исправления, добавляют новый функционал, после чего система автоматически собирает новую версию продукта, или, как ее называют, сборку (build). Каждая такая сборка получает свой уникальный, последовательный номер. Таким образом, версий 3.0.150.30, 3.0.150.31 и 3.0.150.32 совершенно точно существовали, но только в рамках внутреннего контура разработки.
Почему же мы их не видим? Потому что далеко не каждая сборка предназначена для конечного пользователя. Перед публикацией релиз должен пройти строгий многоуровневый контроль качества.
Таким образом, публичный релиз — это та сборка, которая успешно выдержала все испытания. Все промежуточные, нестабильные или просто неудачные версии остаются внутри компании, а их номера мы "пропускаем".
Еще одна причина пропусков в нумерации — существование так называемых технологических релизов. Это специальные версии, которые не несут нового функционала для пользователя, но выполняют важную служебную задачу.
Представим, что разработчики вносят серьезные изменения в структуру базы данных. Прямое обновление со старой версии на новую может привести к ошибкам или потере данных. Чтобы переход был плавным и безопасным, создается промежуточный технологический релиз. Его единственная цель — корректно обновить структуру данных, подготовив ее к следующему, уже функциональному обновлению. Часто такие релизы устанавливаются "под капотом" в процессе обновления и не афишируются как отдельная версия для конечного пользователя.
Разработка крупных программных продуктов ведется в нескольких параллельных ветках. Разберем на примере:
3.0.151.X, которое добавит поддержку новых законодательных норм. Работа над ним долгая, и в процессе создаются десятки внутренних сборок.3.0.150.29 обнаруживается критическая ошибка, например, неправильный расчет налога, которую нужно исправить немедленно. Для этого создается отдельная ветка, и в ней быстро готовится исправительный релиз.В итоге исправительный релиз, который получил номер 3.0.150.33, будет готов и выпущен гораздо раньше, чем большое обновление 3.0.151.X. Это также вносит свою лепту в нелинейность нумерации, видимой пользователю.
Иногда случается и так, что релиз уже был опубликован, пользователи начали его скачивать, но постфактум в нем обнаружилась серьезная проблема. В такой ситуации фирма "1С" может отозвать проблемный релиз — то есть убрать его с портала обновлений и из всех официальных источников.
Пользователи, которые успели обновиться, получат рекомендации по устранению проблемы или дождутся следующего, исправленного релиза. Для всех остальных отозванная версия просто "исчезнет", создавая еще один разрыв в последовательности номеров.
Пропуски в нумерации релизов 1С — это не ошибка, а следствие отлаженного и сложного производственного процесса. Это признак того, что компания применяет серьезный контроль качества и до конечных пользователей доходят только стабильные и проверенные версии программного продукта. Кратко перечислим основные причины:
Поэтому, когда вы видите скачок в номерах версий, знайте — это значит, что система контроля качества работает, и вас уберегли от установки потенциально нестабильного обновления.