Есть ли технология подобных прыжков? может есть технология объединения обработчиков обновления?
Хотел бы прыгнуть из 2.5.8.240 сразу в 2.5.8.329 так как штатным способом нужно 6 раз накатывать. По прошлой практике 2 дня каждое обновление в среднем.

Прыжки назад не приветствуются

... вперёд проблем нет, пока они не обнаруживаются

2 дня? Вас пользователи не распнут?

(0) а смысл?

Версия 2.5.8 является версией длительной поддержки (Long term support, LTS). Ориентировочный период поддержки – до апреля 2023

(0) чем вы там 2 дня занимаетесь при обнове?

+(4) прыгайте сразу на 2.5.9

(4) с 2.5.8. потом будет апдейт на 2.5.10

(2) те можно брать полный файл конфигурации и сразу на 2.5.8.329 ? а как же обработчики обновления? рекомендации 1с с какого релиза на какой перемещаться можно?
(4) в 2.5.8.329 по сравнению с 2.5.8.240 много чего добавили и исправили.
(5) зачем в 2.5.9 прыгать? мы на лонге пока посидим пока новый лонг не появиться

(7) 2.5.10

Работа в режиме сервиса 1cfresh
Реализованы новые функции для администрирования баз в сервисе 1CFresh.

(3) 2 дня обновление готовиться накаты быстро

(7) "В течение этого периода планируется выпуск новых версий с развитием функциональности (2.5.9, 2.5.10, ...)."

думаю с 2.5.8 на 2.5.11, или старше; 2.5.10 уже есть в тесте

поднему тему вверх так как еще актуально

В пределах релиза (третья цифра) можете обновляться сразу на последнюю. С появлением версий длительной поддержки, можно обновляться с последней версии длительной версии, на новую версию длительной поддержки или на релизы до нее.

(13) ок огромное спасибо.

(13) сам придумал? Почему тогда 1С сама не перепрыгивает на несколько релизов в пределах третьей цифры?

(14) обновляй последовательно, дольше думать будешь. Или послушаешь советчиков и хапнешь проблем.

Обновление готовится 2 дня, что мешает подготовить крайнее обновление, за выходные накатить 6 релизов, и в конце накатить конфу с доработками?

(15) спасибо, надо думать... у меня тоже вопрос возник, для чего тогда пишут с какого релиза на какой переходить можно... но тогда сам себе ответил чтобы обновления не раздувать те не тащить модули с древних времен... хотя как узнать точно не понятно ЕРП такой монстр что его по два раза в месяц не обновляют, а обновляют когда припрет.

В зависимости от доработанных модулей, мне казалось это очевидно

(16) "не раздувать" в контексте  ЕРП уже звучит смешно.
нужно смотреть по возможным для обновления релизам, выбирая самые "дальние прыжки" из возможных.
дальше нельзя потому что где-то в промежутке поменялись имена метаданных, и при первом запуске данные переносились между таблицами либо еще какой то цирк в том же духе.
если есть вагон времени можно внимательно вычитать процедуры первого запуска и часть из них объединить сделав прыжки более длинными, но это трудозатратная процедура.

(18) те если правильно понял всетаки нужно шаг за шагом обновляться?

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

(19) Следовать рекомендациям 1С нужно. Хочешь срезать углы, тестируй на копии каждый случай.

(19) да, ты получишь более-менее гарантированный результат, шансов поймать ошибку меньше.
у меня была необходимость максимально срезать даунтайм базы и обновление было не срочным - потратил 2+ недели на подготовку обновлений промежуточных, тестирование и переписывание процедур первого запуска, в итоге вместо 8 релизов удалось докатиться до трех. общий даунтайм около 6 часов составил всех устроило.
на 8 обновах бы зависли почти на сутки.

(22) ну если нет ни одного выходного, тогда да.

Раздувайте бюджеты обновления и дальше.
Для ЕРП, КА, УТ 2.4.* всегда была можно обновляться прыгая через релизы, т.к. обработчики обновления шли накопительным эффектом. Реквизиты не удалялись, а помечались с префиксом "Удалить". При переходе на новую подредакцию (вторая цифра), удалялись все ранее помеченные реквизиты и также очищались обработчики обновления предыдущих версий.
Была однажды одна загвоздка с 2.4.7. С 2.4.3 нельзя например было прыгнуть сразу на 2.4.9, без промежуточного обновления на 2.4.7, но даже на этот случай разработчики в 1С позаботились и перед выполнением монопольных обработчиков в обновленной версии 2.4.9 сообщало, что пропущен обязательный релиз.

Что касается рекомендаций обновления и т.д. Не знаю как там построены остальные конфигурации кроме этих трех, но относительно них могу сказать: что рекомендация эта действует только для дистрибутивов с ОБНОВЛЕНИЕМ, при скачивании полного релиза можно накатывать сразу его по правилам, которые я написал ранее.

Откуда я взял инфу с возможностью обновления в релизах 2.4.х без всяких там промежуточных: поищите самостоятельно инфу на партнерском форуме, где ни один раз разработчиками 1С писалось об этих возможностях.
По версии 2.5.8 и версиям LTS можете сами почитать тему на форуме https://partners.v8.1c.ru/forum/topic/2059185?page=0

В общем, учите матчасть господа, а потом давайте свои рекомендации

(24) Ага, идут накопительно, только не учитывают, что в какой-то из поставок объект/реквизит переименовали с префиксом "Удалить" и начинают вылетать обработчики обновления.

Пригуны, я тут КА обновлял не прыгяя на 2.5, последовательно, так таких глюков нахватал, прводки с одного документа на другой перевешивались, а УПП обновлял на следующее обновление - в документе одно подразделение - в проводках другое, прыжки вероятность такого уменьшать точно не будут.

(24) А твои скачки сразу на последний релиз - это экономия бюджета? Насмешил.
В лучшем случае, перед понедельником будет залит пятничный бэкап и обновление вообще не состоится. Зато человек все выходные работал.
Ну раз нет обновления, то можно не платить - экономия.

(27) да ктож так обновляет?

сначала мучают копию, готовят обновление, проверяют наличие "траблов" и ищут пути решения с напильником по необходимости, заодно можно понять - сколько нужно времени для обновления продуктивной базы

если на копии ок, тады с большой вероятностью продуктив обновится без проблем в указанные всем сочувствующим и причастным сроки

+(28) в нормальных конторах еще заставляют пользователей протестировать "свои участки" в обновленной копии - создание документов/договоров, проводки и прочую муть, чтобы проверить, что всё работает и добавленные кастомизации не отвалились (ну там расширения, доп.отчеты и доп.обормотки)

в результете тестов по жалобам пользователей оперативно допиливаются напильником доработки и исправляются ашипки

(28) Так так же долго. Надо же, херак, херак и в продакшен.

(0) будь мужиком, используй обновлятор и не придется прыгать.

(25) >> не учитывают, что в какой-то из поставок объект/реквизит переименовали с префиксом "Удалить" и начинают вылетать обработчики обновления.

Не могу сказать за ERP, но с БП 3.0 (сидели на ней с 2015-го года) с таким столкнулся один единственный раз.
В каком-то из обработчиков делался перенос данных из таблицы, которая в последующих релизах получила префикс "Удалить".

Т.к. конфигурация у нас сильно доработанная, то обновляли мы её значительно реже, чем к ней выпускает обновления 1С. Обновлять последовательно на каждый релиз, который указан в списке допустимых (обновление предназначено для версии 3.0.ххх), для нас было просто неприемлемо. Это занимало бы слишком много времени. С учётом, что каждое обновление обязательно проходило через предварительные тестирования (сначала техническое - перепроведение и перезакрытие периода, а потом пользовательское - по разделам).

Так что поддерживаю оратора в (24). Обновлять в рамках одной редакции можно относительно спокойно, не глядя на то для каких версий выпускаются обновления.
Просто берём полный дистрибутив конфигурации поставщика нужной версии (cf, а не  cfu) и делаем обновление.
Самое страшное, что может случиться, - это косяк в обработчиках обновления с именами реквизитов или таблиц (появление префиксов "Удалить"). Который легко выявляется и лечится.
А вот обновление с редакции на редакцию (с 2.4 на 2.5) лучше делать всё таки с рекомендуемых релизов. Т.к. такое обновление как правило сопряжено с физическим удалением таблиц и реквизитов, а не простым их переименованием. Есть риск данные потерять.

(31) ERP обновлятором :) ты типовую ERP без доработок видел?

(33) у клеентов

(34) Мой склад, Розница....Бизнес Пак....

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

(32) Переход с 2.4 на 2.5 - случай особый. При обновлении с 2.4 на 2.5 я бы рекомендовал не только брать рекомендуемые релизы, но еще и рабочую базу поставить на поддержку (если не поставлена), т.к. в реквизит СтавкаНДС не добавили тип, а переименовали в УдалитьСтавкаНДС, и тут же добавили новый реквизит СтавкаНДС с новым справочным типом. Т.е. сначала через Поддержка -> Обновить конфигурацию провести обновление до типовой - чтобы все СтавкаНДС переименовались в УдалитьСтавкаНДС, а затем (без применения изменений) накатить конфигурацию с доработками. Иначе, в зависимости от погоды на Марсе, тип СтавкаНДС может поменяться с перечисления на справочник, плюс добавится новый реквизит УдалитьСтавкаНДС - что приведет к веселым эффектам после обновления.

поднему тему так как некоторым может быть полезна, буду обновляться по порядку.
прыгнуть не удалось произошла ошибка обработчика обновления  (РегистрыСведений.СловарьСопоставленияНоменклатурыБЭД.ОбработатьДанныеДляПереходаНаНовуюВерсию):

Недопустимое значение параметра (параметр номер '1') (Колонка не принадлежит коллекции)

Технические подробности:
Ошибка выполнения фонового задания ДлительныеОперации.ВыполнитьСКонтекстомКлиента с идентификатором 19d88b4a-0fb0-4aab-89ec-40fc8d69fec3 по причине
Ошибка при вызове метода контекста (ВыгрузитьКолонку)
{РегистрСведений.СловарьСопоставленияНоменклатурыБЭД.МодульМенеджера(246)}:Порция = ОбновляемыеДанные.ВыгрузитьКолонку("СсылкаНаОбъект");
{РегистрСведений.СловарьСопоставленияНоменклатурыБЭД.МодульМенеджера(41)}:ЗаполнитьСловарьСопоставленияНоменклатурыБЭД(Параметры);
{(1)}:РегистрыСведений.СловарьСопоставленияНоменклатурыБЭД.ОбработатьДанныеДляПереходаНаНовуюВерсию(Параметры[0])
{ОбщийМодуль.ОбщегоНазначения.Модуль(5330)}:Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(4721)}:ОбщегоНазначения.ВыполнитьМетодКонфигурации(КонтекстОбработчика.ИмяОбработчика, ПараметрыВызова);
{(1)}:ОбновлениеИнформационнойБазыСлужебный.ВыполнитьОтложенныйОбработчик(Параметры[0],Параметры[1])
{ОбщийМодуль.ОбщегоНазначения.Модуль(5330)}:Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
{ОбщийМодуль.ДлительныеОперации.Модуль(1328)}:ОбщегоНазначения.ВыполнитьМетодКонфигурации(ИмяПроцедуры, ПараметрыВызова);
{ОбщийМодуль.ДлительныеОперации.Модуль(1318)}:ВызватьПроцедуру(ВсеПараметры.ИмяПроцедуры, ВсеПараметры.ПараметрыПроцедуры);

по причине:
Недопустимое значение параметра (параметр номер '1') (Колонка не принадлежит коллекции)

См. также журнал регистрации.
{ОбщийМодуль.ДлительныеОперации.Модуль(891)}:ВызватьИсключение ТекстОшибки;
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(5201)}:ЗаданиеВыполнено = ДлительныеОперации.ЗаданиеВыполнено(ИдентификаторЗадания);
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(5275)}:Если Не ЗавершитьПотокиВыполнившиеФЗ(Потоки, Группы) Тогда
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(3597)}:ОжидатьЗавершениеЛюбогоПотока(Группы);

(37) патч EF_00_00480878_7, или запустить обновление ИМ в один поток

(38) ИБ*

(38) ок спасибо

Я не сторонник прыгать через релизы обновления, но готовлю файл конфигурации (добавляю все нужные мне изменения) на своем компьютере, перегоняю его на сервер. Далее с рабочей базой: Если делать через Поддержка/Обновить конфигурацию..., то говорит: "Обновление не обнаружено". Поэтому делаю Конфигурация/Загрузить конфигурацию из файла... правильно ли? При этом я не уверен предназначена ли загружаемая конфигурация для текущей, не прыгаю ли я через релизы обновления? Можно ли в этом убедиться?

(41) всегда так делал

(0) >>Как безопасно прыгать
https://www.youtube.com/watch?v=C0dpij50jqw

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