Все известно, что обновление конфигураций происходит от одного ключевого релиза к другому. И так как в пределах редакции неиспользуемые реквизиты не удаляются, почему нельзя сразу накатить самый последний релиз? С тем учетом, что в самом последнем релизе есть обработчики обновления для всех предыдущих релизов.

Или все-таки можно

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

(2) Не пробовал, это так размышления

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

На практике: берут копию, обновляют, тестируют результат и принимают решение.

(3) я бывает так делаю. Беру прежнюю типовую чистую (там данных нет и процедуры обновления быстрее) - накатываю все cfu - из результата беру cf и тестю на копии рабочего релиза.

При автоматическом обновлении нельзя обновиться сразу до последнего, не спроста же так придумали в компании 1С

(0) касательно розницы, обновил с непоследней 1.0 до последней 2.1 в 2 скачка с сохранением данных.

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

На файловой базе проблем быть не должно. Там действительно все обработчики обновления и конвертации данных будут выполняться последовательно. В клиент-серверной базе обработчики обновления делятся на два типа:
- выполняемые в монопольном режиме (назовём их МО)
- отложенные, выполняемые в разделенном режиме фоновым заданием уже после того, как отработают монопольные.
таким образом (назовём их РО).
Таким образом может возникнуть ситуация, когда при обновлении с версии 1.0 на версию 1.2  обработчики в файловой базе выполняться:
МО_1.1 - РО_1.1 - МО_1.2 - РО_1.2
а в клиент-серверной:
МО_1.1 - МО_1.2 - РО_1.1 - РО_1.2

Подобное изменения порядка обработчиков может оказаться критичным если в обновлениях и 1.1 и 1.2 менялись и обрабатывались одни и те же таблицы, но в разных обработчика - в монопольно выполняемых и в раздельно выполняемых.

(8) Спасибо за развернутый ответ

А если в объекты конфигурации добавлены новые "свои" реквизиты, тогда есть вероятность потерять данные по ним с таким обновлением?

за технологию обновления из (8) кому-то на селезневской надо в голову гвоздь забить

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

(10) готовь cf с умом и ничего не пропадет
базу, где ведется БУ (УПП 1.3) обычно обновляю перескоком, т.к. там очень редко что-то меняется

(12) >> в каком-то из релизов эту обработку уберут

С чего вдруг.
Обработчики обновления никто не убирает. Их только добавляют. Если есть обработчик при обновлении на версию, например, 1.1, то он останется и в версии 1.99.

>базу, где ведется БУ (УПП 1.3)

там этого угара и содомии из (8) нету

+(13) вот если бы была та же БП 3.0, то так рисковать, т.к. постоянно вносят кучу изменений

(11) >> надо в голову гвоздь забить

Спорное мнение. Некоторые некритичные обработчики выполняются очень долго. Разделение обработчиков на монопольные и выполняемые раздельно значительно ускоряет процесс обновления больших баз данных.

Хотя само по себе конечно решение неоднозначное.

(8)+ нельзя обновлять если было удаление метаданных, пример:

редакция 0

редакция 1
рекв А переименовали в удалить_а, при этом данные перенесли в новый регистр

редакция 2
рекв удалить_А удалили


при переходе сразй от редакции 0 к редакции 2 мы потеряем данные и регистр будет пустой

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

(18) В типовых так никто не делает.
Внутри одной редакции РеквА останется навсегда с префиксом "Удалить".

(18) так ТС и пишет в топике, что в рамках одной редакции

при автоматической обработке конфигурации бух 2.0 работающей на платформе 3.0  - через интернет - автообработчик полез обновлять конфигурацию с 2.0 на 3.0 особо не спрашивая "с чегойто так надо" ... в результате от автоматических обработок отказались насовсем

в 90% случаях можно (когда понимаешь те варианты , когда это будет с проблемами). С проблемами - просто придется доп. самому вручную данные переносить ,из бекапа например.
Один пример в (18)
Еще пример - проблема при  переименовании. Есть релиз 0 первоначальный. В релизе 1 обработка обновления работает с рекв111 (справочника или документа).
В релизе 2 рекв111 переименован в рекв222 , обработка обновления в релизе 2 уже будет работать с рекв222 . Если мы сразу обновимся с релиза 0 на релиз 2 , то обработка обновления , которая должна была работать в релизе 1 выдаст ошибку , т.к. не найдет рекв111 . Соответсвенно все действия, связанные с этим реквизитом ,  придется отработать самому.

(17) >Разделение обработчиков на монопольные и выполняемые раздельно значительно ускоряет процесс обновления больших баз данных.

чтобы ускорить процесс пусть перерабатывают объектную модель -  запросы на update/insert/delete и т.п.

от процесса обновления требуется одно - чтобы он был "однозначен" - либо он пройден ПОЛНОСТЬЮ и ПОСЛЕДОВАТЕЛЬНО либо нет...

(24) >> от процесса обновления требуется одно - чтобы он был "однозначен"

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