Привет,
Хочу организовать скачки с одной версии на другую внутри своих допилок типовой УТ.
То есть, допустим сейчас я нахожусь на релизе 1.
Нужно что то поменять в конфе, меняем и прыгаем на версию 2.
При обновлении должны запускаться обработчики перехода на версию 2.
Казалось бы типовая так может.. но..
Смотрел в БСП подсистему ОбновлениеВерсииИБ, там процесс запускается только при глобальном изменении Метаданные.Версия.
Хочу организовать скачки с одной версии на другую внутри своих допилок типовой УТ.
То есть, допустим сейчас я нахожусь на релизе 1.
Нужно что то поменять в конфе, меняем и прыгаем на версию 2.
При обновлении должны запускаться обработчики перехода на версию 2.
Казалось бы типовая так может.. но..
Смотрел в БСП подсистему ОбновлениеВерсииИБ, там процесс запускается только при глобальном изменении Метаданные.Версия.
По теме из базы знаний
- Правила и приемы доработки типовых конфигураций 1С для облегчения их дальнейшей поддержки и обновления
- Прием программирования, минимизирующий изменения в модулях управляемых форм при доработке типовых конфигураций и сокращающий время обновления при переходе на новую версию
- Как читать чужой код? Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации
- Технология доработки типовой конфигурации с использованием конфигуратора
- Доработка типовой конфигурации в 1С:EDT. Разработка, тестирование, слияние, выпуск
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(7) То есть считаете нормально, если я дописал строку кода и хочу тем не менее посчитать это новой версии, то через ЗапуститьОбновлениеИнформационнойБазы конфа перезапустит ВСЕ обработчики обновления. Как если бы это был новый релиз типовой..
Думаю так неправильно.
Думаю так неправильно.
(9) (10) Давайте тогда еще раз - правильно я понимаю, что предлагается внести свой модуль ОбновлениеИнформационнойБазы_БлаБла.. и в рамках него по шаблону вести свои доработки. Как и указано в БСП.. все супер.. я так и хотел и тестировал этот момент..
И теперь самое главное, вы предлагаете на любое изменение моей версии запускаться с ключом ЗапуститьОбновлениеИнформационнойБазы.. и вас не заботит, что он перелопатит всю базу.. и вообще говоря это не быстро происходит...
И теперь самое главное, вы предлагаете на любое изменение моей версии запускаться с ключом ЗапуститьОбновлениеИнформационнойБазы.. и вас не заботит, что он перелопатит всю базу.. и вообще говоря это не быстро происходит...
(11)
Во-первых, зачем на любое изменение делать версию?
Во-вторых, сильно сомневаюсь, что у вас каждое изменение потребует выполнение обработчиков. А их тех, которые потребуют, большинство сможет выполниться в фоновом режиме.
В-третьих, далеко не всю базу. Повторное выполнение обработчиков идет значительно быстрее, т.к. данные уже обработаны.
В-четвертых, мы вам ничего не предлагаем. Вы спросили "как", мы ответили "так, сяк и еще вот эдак". Делать или не делать, и если делать, то как - исключительно ваш выбор и ваша ответственность.
Во-первых, зачем на любое изменение делать версию?
Во-вторых, сильно сомневаюсь, что у вас каждое изменение потребует выполнение обработчиков. А их тех, которые потребуют, большинство сможет выполниться в фоновом режиме.
В-третьих, далеко не всю базу. Повторное выполнение обработчиков идет значительно быстрее, т.к. данные уже обработаны.
В-четвертых, мы вам ничего не предлагаем. Вы спросили "как", мы ответили "так, сяк и еще вот эдак". Делать или не делать, и если делать, то как - исключительно ваш выбор и ваша ответственность.
(19) Ну все так. Просто я иду еще дальше в своем вопросе.. я хочу номер сборки использовать.
В общем вы рассматриваете данный процесс как что особенное, что нужно утверждать и имеет свой график и тд..
Ну да имеет, но помимо этого каждый пшик должен вызывать изменения номера сборки.. Это в моей идее.
И вот тут вариант с запуском ключа слегка криво выглядит. Притензия не к вам, я просто излагаю свои мысли.
В общем вы рассматриваете данный процесс как что особенное, что нужно утверждать и имеет свой график и тд..
Ну да имеет, но помимо этого каждый пшик должен вызывать изменения номера сборки.. Это в моей идее.
И вот тут вариант с запуском ключа слегка криво выглядит. Притензия не к вам, я просто излагаю свои мысли.
(20) Дайте угадаю, вы до 1С имели опыт промышленной разработки на "взрослых" языках?
Идея-то хорошая и правильная. Вот только ограничения системы делают ее не совсем удобно реализуемой.
К тому же, вы можете не запускать обновление, если знаете что оно не нужно. Вы даже можете свой билд-сервер этому обучить, если у вас таковой имеется.
Идея-то хорошая и правильная. Вот только ограничения системы делают ее не совсем удобно реализуемой.
К тому же, вы можете не запускать обновление, если знаете что оно не нужно. Вы даже можете свой билд-сервер этому обучить, если у вас таковой имеется.
Цитата с ИТС:
Подключение обработчиков обновления в доработанных конфигурациях
При доработке типовых конфигураций часто возникает необходимость добавлять свои документы и справочники. В дальнейшем это приводит также к необходимости создавать свои обработчики обновления. Для этих целей следует использовать следующий подход.
Считаем, что исходная типовая конфигурация становится библиотекой со своими собственными номером версии и обработчиками обновления, а доработанная конфигурация выступает в качестве основной конфигурации с собственным именем и своей нумерацией версий, разработанной на базе этой библиотеки.
Например, в типовой конфигурации БухгалтерияПредприятияКОРП в общем модуле ПодсистемыКонфигурацииПереопределяемый в процедуре ПриДобавленииПодсистем предусмотрена ссылка на общий модуль, который содержит описание типовой конфигурации:
МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыБП");
В общем модуле ОбновлениеИнформационнойБазыБП в процедуре ПриДобавленииПодсистемы указано имя и версия типовой конфигурации, например:
Описание.Имя = "БухгалтерияПредприятияКОРП";
Описание.Версия = "3.0.38.31";
В этом случае можно смело изменить имя и синоним конфигурации на свои собственные, например БухгалтерияПредприятияКОРП_СRM, и ввести свою нумерацию версий конфигурации. Затем создать общий модуль вида ОбновлениеИнформационнойБазы<Сокращение>, например ОбновлениеИнформационнойБазыCRM, и подключить его в конце процедуры ПриДобавленииПодсистем общего модуля ПодсистемыКонфигурацииПереопределяемый:
МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыCRM");
В общем модуле ОбновлениеИнформационнойБазыCRM в процедуре ПриДобавленииПодсистемы указать имя доработанной конфигурации, версию и зависимость от типовой конфигурации, например:
Описание.Имя = "БухгалтерияПредприятияКОРП_СRM";
Описание.Версия = "1.0.1.1";
Описание.ТребуемыеПодсистемы.Добавить("БухгалтерияПредприятияКОРП");
Обработчики обновления для доработанной конфигурации следует размещать в этом же модуле и привязывать их к новой системе нумерации версий: «1.0.0.2» и т. д.
В дальнейшем при каждом обновлении доработанной конфигурации на новую версию типовой конфигурации необходимо будет увеличивать номер версии доработанной конфигурации, для того чтобы сработали все обработчики обновления.
Подключение обработчиков обновления в доработанных конфигурациях
При доработке типовых конфигураций часто возникает необходимость добавлять свои документы и справочники. В дальнейшем это приводит также к необходимости создавать свои обработчики обновления. Для этих целей следует использовать следующий подход.
Считаем, что исходная типовая конфигурация становится библиотекой со своими собственными номером версии и обработчиками обновления, а доработанная конфигурация выступает в качестве основной конфигурации с собственным именем и своей нумерацией версий, разработанной на базе этой библиотеки.
Например, в типовой конфигурации БухгалтерияПредприятияКОРП в общем модуле ПодсистемыКонфигурацииПереопределяемый в процедуре ПриДобавленииПодсистем предусмотрена ссылка на общий модуль, который содержит описание типовой конфигурации:
МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыБП");
В общем модуле ОбновлениеИнформационнойБазыБП в процедуре ПриДобавленииПодсистемы указано имя и версия типовой конфигурации, например:
Описание.Имя = "БухгалтерияПредприятияКОРП";
Описание.Версия = "3.0.38.31";
В этом случае можно смело изменить имя и синоним конфигурации на свои собственные, например БухгалтерияПредприятияКОРП_СRM, и ввести свою нумерацию версий конфигурации. Затем создать общий модуль вида ОбновлениеИнформационнойБазы<Сокращение>, например ОбновлениеИнформационнойБазыCRM, и подключить его в конце процедуры ПриДобавленииПодсистем общего модуля ПодсистемыКонфигурацииПереопределяемый:
МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыCRM");
В общем модуле ОбновлениеИнформационнойБазыCRM в процедуре ПриДобавленииПодсистемы указать имя доработанной конфигурации, версию и зависимость от типовой конфигурации, например:
Описание.Имя = "БухгалтерияПредприятияКОРП_СRM";
Описание.Версия = "1.0.1.1";
Описание.ТребуемыеПодсистемы.Добавить("БухгалтерияПредприятияКОРП");
Обработчики обновления для доработанной конфигурации следует размещать в этом же модуле и привязывать их к новой системе нумерации версий: «1.0.0.2» и т. д.
В дальнейшем при каждом обновлении доработанной конфигурации на новую версию типовой конфигурации необходимо будет увеличивать номер версии доработанной конфигурации, для того чтобы сработали все обработчики обновления.
Допустим УТ версии 11.2 (условно) и мы сидим на этом релизе.
В рамках релиза делаем свои доработки и версионируем их через свой модуль.
Так вот, при выходе нашей доработки-выходе нашего обновления ЗапуститьОбновлениеИнформационнойБазы начнет снова процедуры обновления на релиз 11.2 и это будет не быстро.
Например возмите любую свою типовую базу и запуститесь с этим ключем, программа реально начнет запускать все обработчики. она не пропускает их, а рельано делает то что написано в обработчкиках. То есть перезаполнит регистры, справочники и тд, то есть сделает все то что запланировно в обработчиках.
В рамках релиза делаем свои доработки и версионируем их через свой модуль.
Так вот, при выходе нашей доработки-выходе нашего обновления ЗапуститьОбновлениеИнформационнойБазы начнет снова процедуры обновления на релиз 11.2 и это будет не быстро.
Например возмите любую свою типовую базу и запуститесь с этим ключем, программа реально начнет запускать все обработчики. она не пропускает их, а рельано делает то что написано в обработчкиках. То есть перезаполнит регистры, справочники и тд, то есть сделает все то что запланировно в обработчиках.
(14) (15)
Хорошо, спасибо! Я проверю этот момент, пока при тесте и при запуске с таким ключом процесс ощутимо долго шел. И выполненные обработчики вообще не быстро "пролетали".
Кроме того согласитесь, здесь есть кривота.. нужно помнить про этот ключ, я то надеялся что БСП сможет сама понимать что изменилась именно версия моей подсистемы и обновить только ее без всяких ключей.
А не знаете там можно через макет выводить список своих изменений, вроде в коде подводки есть, но тоже не уверен.
Хорошо, спасибо! Я проверю этот момент, пока при тесте и при запуске с таким ключом процесс ощутимо долго шел. И выполненные обработчики вообще не быстро "пролетали".
Кроме того согласитесь, здесь есть кривота.. нужно помнить про этот ключ, я то надеялся что БСП сможет сама понимать что изменилась именно версия моей подсистемы и обновить только ее без всяких ключей.
А не знаете там можно через макет выводить список своих изменений, вроде в коде подводки есть, но тоже не уверен.
(16)
Предполагается, что невозможно изменить версию части программы без изменения версии самой программы. Что, как бы, логично :)
Чем вас не устраивает вариант (4)?
Ну, да, если вы хотите пакет доработок оформить отдельной подсистемой и отдельно ее версионировать, то придется при каждой допилке менять и ее версию и версию всей конфы и прописывать зависимости версий конфы от версий подсистем. Зато все четко и по полочкам, как и должно быть.
я то надеялся что БСП сможет сама понимать что изменилась именно версия моей подсистемы и обновить только ее без всяких ключей
Предполагается, что невозможно изменить версию части программы без изменения версии самой программы. Что, как бы, логично :)
Чем вас не устраивает вариант (4)?
Ну, да, если вы хотите пакет доработок оформить отдельной подсистемой и отдельно ее версионировать, то придется при каждой допилке менять и ее версию и версию всей конфы и прописывать зависимости версий конфы от версий подсистем. Зато все четко и по полочкам, как и должно быть.
(21) Что здесь логичного?
Есть конфа, в ней есть некий механизм, есть некие подсистемы которые версионируются.
Каждая версионируется отдельно.
Я хочу чтобы моя подсистема могла версионироватьи скакать по релизам абсолютно отдельно от всех.
По крайней мере была такая надежда и идея.
Но БСП такое может с оговорками, в любом случае всега можно сказать - сделайте сами и будете правы.
Но идея моя очень простая и логичная, а вот как работает как раз не очень логично и удобно.
Есть конфа, в ней есть некий механизм, есть некие подсистемы которые версионируются.
Каждая версионируется отдельно.
Я хочу чтобы моя подсистема могла версионироватьи скакать по релизам абсолютно отдельно от всех.
По крайней мере была такая надежда и идея.
Но БСП такое может с оговорками, в любом случае всега можно сказать - сделайте сами и будете правы.
Но идея моя очень простая и логичная, а вот как работает как раз не очень логично и удобно.
(23)
Вы что, не согласны с тем, что обновляя версию библиотеки в составе продукта нужно изменить и версию продукта тоже?
(23)
Но релизы продукта (конфы) при этом тоже должны меняться. И должна быть четкая зависимость между версиями продукта (конфы) и версиями библиотек (подсистем). Это ж типа общепринятая практика в мире программирования.
В БСП уже все предусмотрено для этого. Типовая функциональность УЖЕ оформлена отдельной подсистемой. Просто нумерация релизов этой подсистемы и продукта совпадает. В (4) описано как добавить свою подсистему и перевести релизы продукта на ее нумерацию. Ну а если вы хотите, чтобы не пришлось менять релиз вашей подсистемы при обновлении других подсистем (отвязать от нумерации релизов продукта), тогда для релизов продукта потребуется отдельная подсистема. В итоге нумерация релизов у всех подсистем (включая вашу) будет независимой, но при любом изменении продукта должна измениться и его версия. И должны быть правильно прописаны зависимости версий подсистем.
Что здесь логичного?
Вы что, не согласны с тем, что обновляя версию библиотеки в составе продукта нужно изменить и версию продукта тоже?
(23)
Я хочу чтобы моя подсистема могла версионироватьи скакать по релизам абсолютно отдельно от всех.
Но релизы продукта (конфы) при этом тоже должны меняться. И должна быть четкая зависимость между версиями продукта (конфы) и версиями библиотек (подсистем). Это ж типа общепринятая практика в мире программирования.
В БСП уже все предусмотрено для этого. Типовая функциональность УЖЕ оформлена отдельной подсистемой. Просто нумерация релизов этой подсистемы и продукта совпадает. В (4) описано как добавить свою подсистему и перевести релизы продукта на ее нумерацию. Ну а если вы хотите, чтобы не пришлось менять релиз вашей подсистемы при обновлении других подсистем (отвязать от нумерации релизов продукта), тогда для релизов продукта потребуется отдельная подсистема. В итоге нумерация релизов у всех подсистем (включая вашу) будет независимой, но при любом изменении продукта должна измениться и его версия. И должны быть правильно прописаны зависимости версий подсистем.
(21) (22) Еще раз.. да какие ограничения, то.. могу точно также в конфу внести константу и может еще регистр и полностью сам все сделать. При каждом запуске проверять "текущую" версию и "новую". Далее запускать нужные процессы. Как минимум изменения версии (номера сборки).
Надеялся на БСП и в этом виновен, все)
Надеялся на БСП и в этом виновен, все)
Вы что, не согласны с тем, что обновляя версию библиотеки в составе продукта нужно изменить и версию продукта тоже?
Конечно не согласен!
Я то и хочу - дорабатываем типовую и в своей подсистеме ведем свою версионность, вообще нет никакиз зависимостей. Я не хочу ничего знать про версию конфы. Мне важны только мои версии.
(28) В момент доработки типовая конфа становится нетиповой. В (4) описана методика перехода на нумерацию релизов для нетиповой конфы с сохранением нумерации типовой конфы как отдельной подсистемы в ее рамках. Т.е. просто делаете как в (4) и выпускаете гордый релиз "Покоцанная типовая" 1.0.1.0 с добавлением первого документа.
Добавляете второй документ - меняете версию конфы и подсистемы на 1.0.2.0.
Надо обновить типовую функциональность - обновляете и выпускаете 1.1.0.0 (если все сделано по методике, то при обновлении автоматом выполнятся и все обработчики обновления типовой функциональности).
Добавляете второй документ - меняете версию конфы и подсистемы на 1.0.2.0.
Надо обновить типовую функциональность - обновляете и выпускаете 1.1.0.0 (если все сделано по методике, то при обновлении автоматом выполнятся и все обработчики обновления типовой функциональности).
(30) Как описано в (4) я первым делом попробовал.
Да, добавляется свой модуль, да там можно вестисвою версионность, обработчики и тд.. казало бы вот оно.
НО, если я в своем модуле меняю версию, то конфа не может это обнаружить. Нужно запускаться со спец ключом, а в таком случае будут попытки опять по всем версиям перепройти. Чтото выполнится, чтото нет. Вот мне показалось, что это достаточно долго и стремно. Хотя как мне рассказали тут, в таком случае не все обработчики запускаются а только "обязательные".
Это нужно проверить.
Даже если так, для себя я вижу тут неудобство.. буду думать как обойти. Неудобство в том, что при изменении моей версии я не хочу ни от чего зависеть и обновить только ее. Как то так.
Да, добавляется свой модуль, да там можно вестисвою версионность, обработчики и тд.. казало бы вот оно.
НО, если я в своем модуле меняю версию, то конфа не может это обнаружить. Нужно запускаться со спец ключом, а в таком случае будут попытки опять по всем версиям перепройти. Чтото выполнится, чтото нет. Вот мне показалось, что это достаточно долго и стремно. Хотя как мне рассказали тут, в таком случае не все обработчики запускаются а только "обязательные".
Это нужно проверить.
Даже если так, для себя я вижу тут неудобство.. буду думать как обойти. Неудобство в том, что при изменении моей версии я не хочу ни от чего зависеть и обновить только ее. Как то так.
(33) Согласен, я перечитаю и перепопробую. Возможно чтото упускаю.
(34) Метаданные я вообще не хочу трогать. Вся конфа истыкана обращением Метаданные.Версия.. ну и что будет если туда начнет приходить моя версия.. Нет, не хочу.
Изначально идея сидеть на типовом релизе, в шапке конфы ничего не трогать, ни версию ни название. И все изменения вести в своем модуле, своей подистемы. Я вижу это как абсолютно независимую штуку.
Ок, вы убеждаете меня что все по другому обстоит.. Я должен разобраться тогда)
(34) Метаданные я вообще не хочу трогать. Вся конфа истыкана обращением Метаданные.Версия.. ну и что будет если туда начнет приходить моя версия.. Нет, не хочу.
Изначально идея сидеть на типовом релизе, в шапке конфы ничего не трогать, ни версию ни название. И все изменения вести в своем модуле, своей подистемы. Я вижу это как абсолютно независимую штуку.
Ок, вы убеждаете меня что все по другому обстоит.. Я должен разобраться тогда)
(35) Все сидят на типовом релизе, потому что никто не заморачивается с собственными нумерациями. И так безопаснее - я с этим готов согласиться. Потому что если криворукие разработчики в каких-то интеграционных обработках (например) завязались на версии и названия напрямую из метаданных, а не из подсистем - то в этом месте может сломаться. Там тоже люди работают и люди разные, а такая схема не настолько популярна, чтобы выгрести все баги, если они где-то есть.
Но вы же завели разговор о том "как правильно версионировать" :) А правильно - именно так. БСП реализует именно правильный вариант и грех на нее пенять.
Другое дело, что в чудесном мире 1С "правильно" и "лучше" - не всегда одно и тоже :)
Так что если хотите и гарантий отсутствия проблем и выполнения своих обработчиков не трогая релиз продукта - лучше всего доработать механизм обновлений БСП. Чтобы изменения версии вашей подсистемы анализировались всегда, а не только при изменении версии продукта.
Но вы же завели разговор о том "как правильно версионировать" :) А правильно - именно так. БСП реализует именно правильный вариант и грех на нее пенять.
Другое дело, что в чудесном мире 1С "правильно" и "лучше" - не всегда одно и тоже :)
Так что если хотите и гарантий отсутствия проблем и выполнения своих обработчиков не трогая релиз продукта - лучше всего доработать механизм обновлений БСП. Чтобы изменения версии вашей подсистемы анализировались всегда, а не только при изменении версии продукта.
(32) Я не понимаю, как вы не понимаете :) Забудьте про спец-ключ запуска. Это костыль для нестандартных ситуаций, которые мы сейчас не рассматриваем.
При ЛЮБОМ изменении доработанной конфы (типовая функциональность или ваши доработки изменились - не важно), должен измениться релиз конфы (в (30) это релиз подсистемы "Покоцанная типовая"). Допустим, вы обновили версию своей подсистемы "Мои прекрасные разработки". Отлично. Тут же меняете версию подсистемы "Покоцанная типовая" и В МЕТАДАННЫХ ТОЖЕ. При первом запуске БСП определит изменение версии продукта, увидит что продукт зависит от вашей подсистемы, увидит что изменилась версия вашей подсистемы и запустит необходимые обработчики (и только их).
При ЛЮБОМ изменении доработанной конфы (типовая функциональность или ваши доработки изменились - не важно), должен измениться релиз конфы (в (30) это релиз подсистемы "Покоцанная типовая"). Допустим, вы обновили версию своей подсистемы "Мои прекрасные разработки". Отлично. Тут же меняете версию подсистемы "Покоцанная типовая" и В МЕТАДАННЫХ ТОЖЕ. При первом запуске БСП определит изменение версии продукта, увидит что продукт зависит от вашей подсистемы, увидит что изменилась версия вашей подсистемы и запустит необходимые обработчики (и только их).
(30) (33) Я внимательно прочитал статью на ИТС, и то что написано в (4) похоже на то что мне нужно.
Но самый главный вопрос - это же получается нужно менять версию в шапке Метаданные.Версия.
А как тогда быть с многочисленными местами в конфе где как раз напрямую идет обращение к Метаданные.Версия. После изменения, туда начнет приезжать МОЯ версия.
Хочу подчеркнуть, речь идет о мире типовых где нужно обойтись минимальным количеством изменений.
Но самый главный вопрос - это же получается нужно менять версию в шапке Метаданные.Версия.
А как тогда быть с многочисленными местами в конфе где как раз напрямую идет обращение к Метаданные.Версия. После изменения, туда начнет приезжать МОЯ версия.
Хочу подчеркнуть, речь идет о мире типовых где нужно обойтись минимальным количеством изменений.
(40) Если эти ссылки вы находите только внутри объектов подсистем БСП, то они не должны создать проблем. В конце концов, инструкция по переходу была из документации к БСП :)
Но так как я лично такие переходы для типовых конфигураций не осуществлял на продакшене, то ессно стоит погонять на копиях. Обязательно попробовать произвести обновление типовой, чтобы убедиться что все взаимосвязи работают правильно и отрабатывают стандартные обработчики при обновлении.
ЗЫ. У меня есть самописка на базе БСП, которую я дорабатываю с изменением версий. При структурных изменениях меняю номер релиза подсистемы и конфы (при минорных обновлениях ленюсь), пишу обработчики перехода когда надо.
Но так как я лично такие переходы для типовых конфигураций не осуществлял на продакшене, то ессно стоит погонять на копиях. Обязательно попробовать произвести обновление типовой, чтобы убедиться что все взаимосвязи работают правильно и отрабатывают стандартные обработчики при обновлении.
ЗЫ. У меня есть самописка на базе БСП, которую я дорабатываю с изменением версий. При структурных изменениях меняю номер релиза подсистемы и конфы (при минорных обновлениях ленюсь), пишу обработчики перехода когда надо.
(41) По факту эти ссылки не только внутри БСП, как я описал их полно в других местах.. ну смотреть нужно.. Вот как лично я посмотрел это не критичные моменты. Просто вам пишу, что по факту такие места точно есть, можете сами глянуть.
А то что вы пример свой рассказываете, согласитесь это как раз простой понятный пример. В моем вопросе вся фишка провернуть трюк с типовой.
(42) Жесть, страшилка.. Вот смотрите, по факту как в (4) описано я вроде потестил, норм получается.
Только в фоне осталось сомнение.. Выходит мы полностью срубаем в шапке типовую версию (!) и гордо лицезреем там свой релиз 1.0.1.1.. Страшно, однако)
А то что вы пример свой рассказываете, согласитесь это как раз простой понятный пример. В моем вопросе вся фишка провернуть трюк с типовой.
(42) Жесть, страшилка.. Вот смотрите, по факту как в (4) описано я вроде потестил, норм получается.
Только в фоне осталось сомнение.. Выходит мы полностью срубаем в шапке типовую версию (!) и гордо лицезреем там свой релиз 1.0.1.1.. Страшно, однако)
(46) К примеру, Рарус оставляет мажорную и минорную версию типовой и меняет только последние цифры в ревизии.
Вот полностью своя конфигурация на базе БСП позволяет делать свой номер версии. Там нет необходимости описывать обработчик перехода мажорной версии. Версия с самого начала нумеруется.
Вот полностью своя конфигурация на базе БСП позволяет делать свой номер версии. Там нет необходимости описывать обработчик перехода мажорной версии. Версия с самого начала нумеруется.
(45) вот не надо так кардинально менять версию в метаданных. Там потребуется описывать обработчики перехода на новую мажорную и минорную версию. Обычно они проверяются.
Стоит менять версию ревизии или в крайнем случае билда. Мажорную и минорную оставить родную.
Другими словами на примере Розница. Родная версия 2.2.7.39. Меняем последние цифры в сторону увеличения.
Стоит менять версию ревизии или в крайнем случае билда. Мажорную и минорную оставить родную.
Другими словами на примере Розница. Родная версия 2.2.7.39. Меняем последние цифры в сторону увеличения.
(49) и (50) То есть вы опять заводите тему что срубать версию типовой не надо)
А вот после прочтения (4) и изучения ИТС получается что все таки надо и можно.
Типовая версия в таком случае становится зависимой подсистемой, мажорные и минорные релизы тут не при чем.
А вот после прочтения (4) и изучения ИТС получается что все таки надо и можно.
Типовая версия в таком случае становится зависимой подсистемой, мажорные и минорные релизы тут не при чем.
(52)
Может я не ясно выразился. Это не разные релизы.
На примере выше про Розницу. Версия. 2.2.7.39
2 - мажорная версия
2 - минорная версия
7 - билд
39 - ревизия.
В 1С они могут несколько иначе называться, но суть та жа.
мажорные и минорные релизы тут не при чем
Может я не ясно выразился. Это не разные релизы.
На примере выше про Розницу. Версия. 2.2.7.39
2 - мажорная версия
2 - минорная версия
7 - билд
39 - ревизия.
В 1С они могут несколько иначе называться, но суть та жа.
(55) я вас не заставляю. Но именно так делают отраслевые на базе типовых.
Не совсем так. Вышла типовая 2.2.7.39. Свой релиз той же версией указываем. При дополнительных изменения свой подсистемы инкрементируем ревизию.
Сквозная нумерация теряется. А она нужна?
к примеру 2.2.7.39 - типовой.. по вашей идее меняем 2.2.7.40
Не совсем так. Вышла типовая 2.2.7.39. Свой релиз той же версией указываем. При дополнительных изменения свой подсистемы инкрементируем ревизию.
Сквозная нумерация теряется. А она нужна?
(57)
Так зачем? Не думали, почему версия состоит из 4 наборов цифр а не одним набором сквозной нумерации?
По текущей версии можно легко ориентироваться на актуальность вашего решения. Что актуальный типовой релиз выпущен год назад, а у вас еще обновление не выпущено.
Конечно нужна полностью своя явная сквозная нумерация.
Так зачем? Не думали, почему версия состоит из 4 наборов цифр а не одним набором сквозной нумерации?
По текущей версии можно легко ориентироваться на актуальность вашего решения. Что актуальный типовой релиз выпущен год назад, а у вас еще обновление не выпущено.
(58) Мне кажется вы рассматриваете какой то свой сценарий.
Что нужно мне - Представим проект по УТ. Вы занимаетесь доработкой решения и хотите все свои доработки версионировать. В таком случае мы подменяем версию в шапке, типовая версия становится зависимой подсистемой.
Далее вы живем в своей версии, поднимаем ее в процессе доработки. При выходе новой версии типовой также поднимаем свою версию и этим вызываем обработчики обновления типовой также. То есть они шагают вместе из релиза в релиз, а наша версионность растет от 1.0.1.0 релиза в процессе доработок и выхода типовых.
Это предлагается делать на ИТС.
Менять 3 и 4 цифры не вижу смысла, это запутано, это неправильно и это потому что вы исходите из того, что там чтото сломается. Ну может, но не должно.
Что нужно мне - Представим проект по УТ. Вы занимаетесь доработкой решения и хотите все свои доработки версионировать. В таком случае мы подменяем версию в шапке, типовая версия становится зависимой подсистемой.
Далее вы живем в своей версии, поднимаем ее в процессе доработки. При выходе новой версии типовой также поднимаем свою версию и этим вызываем обработчики обновления типовой также. То есть они шагают вместе из релиза в релиз, а наша версионность растет от 1.0.1.0 релиза в процессе доработок и выхода типовых.
Это предлагается делать на ИТС.
Менять 3 и 4 цифры не вижу смысла, это запутано, это неправильно и это потому что вы исходите из того, что там чтото сломается. Ну может, но не должно.
(40) Поделюсь немного своим опытом в отношении использования подсистемы "Версии ИБ" так, как это описано в (4). Гарантированно этот способ будет работать только в собственной конфигурации, построенной на базе БСП, не на базе другой типовой конфигурации, которая в свою очередь содержит БСП. У меня была неудачная попытка сделать свою подсистему основной в ERP. Но как оказалось, имя конфигурации изменить на свое я не могу, потому как внезапно оно тоже используется в модулях, и более того, в зависимости от него устанавливаются значения некоторых функциональных опций. В результате пришлось отказаться от идеи сделать свою подсистему с собственной нумерацией версий основной, и остановиться на варианте запуска ИБ после обновления с использование специального ключа (параметра): /СЗапуститьОбновлениеИнформационнойБазы.
(42)
Жесть. А можно пруф? Навскидку такого не нашел.
Если так, то разрабочикам некоторых типовых пофиг на базовые концепции БСП. Они должны были из подсистем эту инфу брать, а не из метаданных.
Но как оказалось, имя конфигурации изменить на свое я не могу, потому как внезапно оно тоже используется в модулях, и более того, в зависимости от него устанавливаются значения некоторых функциональных опций.
Жесть. А можно пруф? Навскидку такого не нашел.
Если так, то разрабочикам некоторых типовых пофиг на базовые концепции БСП. Они должны были из подсистем эту инфу брать, а не из метаданных.
(43) Да, проверил ERP 2.4.3.160, нашел только одно место проверки конфигурации по имени. Это процедура "ПередОбновлениемИнформационнойБазы" общего модуля "ОбновлениеИнформационнойБазыПереопределяемый". Ну и небольшая мелочь - поиска подстроки "БАЗОВАЯ" для проверки, базовая ли это конфигурация.
В общем, вроде все хорошо, можно пробовать менять имя конфигурации, поправив только одно место в модулях. Восстанавливать ERP 2.2 уже не буду для проверки. Что было, то было. Может это я где допустил ошибку. :)
В общем, вроде все хорошо, можно пробовать менять имя конфигурации, поправив только одно место в модулях. Восстанавливать ERP 2.2 уже не буду для проверки. Что было, то было. Может это я где допустил ошибку. :)
(28) Ну а если вы хотите таки оформить свои супер-модульные доработки отдельной подсистемой, тогда просто кроме подсистемы "Покоцанная типовая" добавляете еще и подсистему "Мои прекрасные разработки". В итоге при изменении и версии типовой функциональности и версии "Мои прекрасные разработки" нужно будет менять версию "Покоцанной типовой".
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот