Есть средне-модифицированная УТ, я посчитал, что там 5 переходов по конфам (с весны 2020 по текущий релиз).
Ну если по-хорошему, то как обновляем:
1. Сравниваем текущую с последней, переносим изменения в последнюю.
2. Далее просто последовательно путем "Обновить из файла" накатываем ключевые конфы (с потерей доработок, потому что они из последней конфы войдут)
3. Ну и после накатывания запускаем 1С.
Так я понимаю?
Или кто-то по рабоче-крестьянски сразу на последнюю обновляет? Я помню, нарвался на контроль, что с такой-то версии на такую-то нельзя перейти. Отключил его конечно, но гимор еще тот был....

Ещё можно, например, похерить данные в каком-нибудь реквизите который менял тип/местонахождение и поочередные обновления обеспечивали сохранность этих данных.

(1) да это я понимаю, поэтому предложил клиенту два варианта - дешевый и рискованный и дорогой и по методичке.

Меня больше смущает пункт 2, что я накатываю конфу, где теряются доработки, при этом понимаю, что там объединение происходит, т.е. данные остаются, но все же.

Скромно-гениальное решение...

(0)
1. Вынести все доработки в Расширение
2. Обновить
3. Допилить расширение под обновленную УТ

(5)+ Забыл

0. Нанять программиста

>Я помню, нарвался на контроль, что с такой-то версии на такую-то нельзя перейти. Отключил его конечно, но гимор еще тот был....

гыгы

(2) Интересный клиент пошел, раньше клиенту был важен результат. А теперь процесс ?

(8) Сейчас клиенту надо вникать в процесс или обуют и говно подсунут.

(8) у клиента должна быть свобода выбора, имхо.

(0) >> с весны 2020 по текущий релиз
Это 1 редакция? Тупо обновить свежей конфигурацией не предлагать?

(11) 11.4.11.71 на 11.4.13.71

(5) да, это я тоже предложил.

(12) Последнюю всё равно готовить, поэтому
1. Обновляем на последнюю
2. Если "нарвался на контроль" и т.п. - делаем промежуточные обновления
На практике с п.2 никогда не сталкивался с типовыми от 1С в пределах одной редакции.

(14) ну это да, верно. ну не знаю, я озвучил клиенту "скидку на риск", его дело - идти на него или нет.

Жаль, что 1с не пишет, почему нельзя пропускать релизы в комментариях к схеме переходов. Класссический черный ящик

(14) У меня есть дека от 1С ут11 на которую я накатываю свежий релиз в режиме предприятия (т.е. способом предусмотренным разработчиками). На практике уже пару раз точно она ломалась. Т.е. процедуры обновления нарывались на ошибку и переход на новую версию не завершался. И это на демка, где 1,5 документа

(17) Это к чему? не очень понял. В режиме предприятия вроде как раз все(какие положено) промежуточные накатываются. Понятно что чем больше обновлений тем больше шансов поймать косячное.
К вопросу можно ли пропустить промежуточные, вроде прямого отношения не имеет. И даже наоборот: пропустив промежуточные есть шанс избежать встречи с явно кривыми релизами.

(18) После наката запускаются куча разных процедур для перехода. Вот они не всегда отрабатывают. Короче даже если делать все последовательно не значит что все пройдет без проблем

(18) ну все фанатично не надо, там же есть ключевые, по ним и строится схема перехода, они вряд ли косячные

(19) но проблем будет меньше таки

"По методичке" нужно ещё и конфу поставщика обновлять.

(20) Нет никаких "ключевых", если об этом не указано явно. Если мы говорим про cfu, то там просто указываются релизы для которых он содержит обновления.

(21) или больше, если промежуточные релизы с ошибками

(22) Её вообще невозможно НЕ обновить, если делать обновление. Есть мастера, которые делают объединение, но это совсем другая история))

Через стандартные "Поддержка - Обновить Конфигурацию" обновиться до нужного релиза. Все добавленные объекты останутся на месте и данные не пропадут. Если есть изменения в ОМ, МО и ММ, то в режиме настройки объединения выставить так что бы свои изменения не пропали. После этого перенести в получившуюся конфу изменения всяких форм.

зы можно еще на этапе обновления анализировать изменения форм и сразу принимать решения... но это тогда придется повозиться.

(26)+ и что бы потом вот так не мучатся... я свои УТ обновляю только на последние релизы... Вышла последняя 11.4.10.* обновился на нее... Вышла потом последняя 11.4.11.* перешел на нее... и т.д.

(27) ну я не веду клиента, просто привлечь хотят к обновлению. ;-)

В общем, обновил на последнюю конфу, без промежутков. Сегодня буду наблюдать.

(29) Если обновление прошло без ошибок, то всё что может вылезти никак не связано с пропущенными релизами.

(30) так я наблюдать буду как раз за ошибками, которые выстрелят. Парочку и так нашел, простым тестированием.

А чего такого трудоемкого в накатывании через поддержку последовательно релизов с оставлением добавленных объектов и забиванием на код? Ну а в последнем уже вылизать все.

(32) Время. И риск собрать ошибки, которые мог пропустить.

(16) > Жаль, что 1с не пишет, почему нельзя пропускать релизы в комментариях к схеме переходов. Класссический черный ящик

Накати на копию, выгрузи в файлы, дифани.

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

(32) время. мне его не подтвердили, пошли по короткому пути с одним обновлением

(35) Непонятно
1. почему надёжнее
2. зачем делать ненужную работу, и искать в это ещё компромисс.

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

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

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

(16) этого не знает даже САМ

(38) может и пример приведёшь, когда в типовых так сделали, а предупредить забыли.
Там поэтому и копятся эти "Удалить...", что удаляют их только со сменой редакции, или явно указывают - переход возможен с релиза не ниже XX, но такое считанные разы видел

Для меня всегда предупреждением служил список версий, для обновления которых предназначен релиз. Может и ошибался. Конкретно на описанный косяк попадал как-то раз еще во времена существования бухи 1.6. С тех пор всегда старался четко придерживаться написанного, так что примерам взяться неоткуда. :)

(41) прости, а где они предупреждают? Где их Рупор, так сказать?

(42) Ну список там параноидальный. Может там какой ЕГАИС радикально менялся, к чему это обычной оптовой конторе. Список там видиши ли, общий, не описано что и почему

(42) А это не просто список релизов, для которых есть обновление в cfu?
(43) На странице скачивания обновлений, видел такое пару раз. Пример сейчас вряд ли найду.

Все здесь. Никита, Стас..
За 10 лет ничего не поменялось..

5 релизов всего? ха! это ж не 10.
сначала при обновлении обновляете без удаления реквизитов из доработок.
после обновления на последний релиз переносите доработки в формах.

(47) это понятно, но время на натягивания конф, запуск 1С. Тут уж или обновлятор запрягать или же брать с клиента + 1.5 часа

(48) возьмите 1,5 часа. если клиент откажется, значит будет сидеть со старой конфой и ему это все не очень то и нужно.

(49) да это уже вопрос в прошлом. обновление прошло одним махом. Я не сторонник выкручивания рук. Я честно объяснил, что вероятность косяков не велика.

(48) ну и потом, качаются эти промежуточные релизы тоже долго. Это в фоне надо делать, по идее. А обновлять их можно только ночью. Если только заранее эти релизы накачать. бррр....

(51) как поется в одной композиции - asi el la vida... т. е. "такова жизнь".

https://youtu.be/hEZ843O4SFw

(52) ну это понятное дело.