Да полчаса уже трейсю, тут отраслевка с номером версии конфигурации через слэш и там что-то закомментировано и что-то добавлено в это сравнение. Бле, надоело уже)

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

Можно запустится со спец. параметром "ЗапуститьОбновлениеИнформационнойБазы" и есть обработка

Спец. параметр лишь считает, что надо повторить последнюю итерацию обновления, то бишь как будто это первое сравнение номера версии из кода и номера версии из регистра.
У меня же оно в регистре так и не появилось пока даже.

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

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

ты же можешь сделать две подсистемы - новую главную и свою микро с функциональностью

Чтоб добавить свою библиотеку - в ПодсистемыКонфигурацииПереопределяемый и дальше по инструкции

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

Встраиваем редактор VSCode в Vanessa Automation!
https://youtu.be/cntKcYDRU98

Там же вроде на начальном этапе определяется, требуется ли обновление. Функцией с соответствующим же именем, типа ТребуетсяОбновлениеИнформационнойБазы(), или как-то так. Причем смотрит она только в версию корня. Кроме как дописать там условие проверки из своего модуля ничего особо в голову не приходит, имхо это проще чем менять основную подсистему. Нет, можно, конечно какой-нибудь изврат придумать, типа повышения версии основной в РС, при изменении версии своей подсистемы, но зачем уж так.

Да, смотрит в корень и сравнивает с тем, что в регистре.
Корень трогать точно не хочется, но и как добиться чтоб моя "сбоку" попала в регистр и подтягивалась там автоматом - тоже пока не вкурил)

Не совсем понимаю. Задача вроде как распадается на две. Первая подзадача: добавить свою подсистему, чтобы она подчинялась стандартной логике обновления, т.е. при вызове обновления менялся номер версии в РС, выполнялись обработчики из ОМ "ОбновлениеИнформационнойБазыМояОфигеннаяПодсистема" и т.д. И тут только по документации. Коллеги выше говорят, что вроде нет проблем, хотя я сам не делал, хз.
Вторая подзадача: вызвать обновление без изменения версии основной подсистемы. И тут без изменения этой функции, либо подготовки своей поставки ничего особо и не придумаешь. Ну помимо извратов, упомянутых выше.

Ну вот про первый пункт пока не уверен, что он выполнен, ибо подсистема добавлена по мануалу, но в регистре не появилась

Ух, выглядит круто

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

Коллеги, планируем обновление платформы х64 8.3.15.1778 на более свежую. посоветуйте стабильную версию. Пока склоняюсь к x64 8.3.16.1502

Любой подобный совет всегда имеет ноль смысла

нужны дополнительные входные данные для совета? на ряде платформ есть проблемы со стабильностью, в 1747 например формы со второго раза закрываются.