Автопроставление (авто-поднятие) версий сборки/проекта

[DitriXNew]

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

Для чего? Ответ один и простой, точнее 2:

1. Для конфигураций и расширений - кеши. Особенно при разработке мобильной - это вообще трешь, там кеш на кеше и кешем погоняет. И нифига не понятно - перенеслись изменения или нет.
2. Периодические приколы едт, когда она не обновляет конфу, или не перекомпилирует сборку обработки/отчета.

[marmyshev]

а где ты предлагаешь хранить версию для внешних обработок?

[marmyshev]

Для расширений и конфигурации - совсем не проблема сделать авто-подъем версии.

Вопрос - в какой момент менять версию? судя по проблемам которы ты описываешь - надо перед каждой заливкой в ИБ менять (т.е. перед каждым экспортом в xml)

всё остально (шаблоны, файлы и т.д.) - вроде нет сложностей сделать. Кто бы захотел сделать! ;) Есть желающие?

[DitriXNew]

а где ты предлагаешь хранить версию для внешних обработок?
Та прям в ней, особенно для подключемых в БСП, там прям есть специальное место в модуле объекта.

А то надоело когда разрабы делают что то, версию не поднимают, кидают клиентам, и клиент пишет тикет, типо - вот в такой версии. А разраб типо - ну я там только одну строку добавил, и забыл версию поменять :)

А всех в контур не закинешь, вот и мучаешься. Но последняя капля - это эти гребанные кеши :(

[marmyshev]

Вопрос - в какой момент менять версию?

Всё-таки, это не понятно, как ожидается чтобы система работала.

Например. Если при загрузке в ИБ - вот 100500 раз запустил отладку - получишь +100500 номеров в версии.

Если ручное действие по инкриментации - то будут так же забывать.

[Jimmi910]

Менять версию при Фиксации коммита.
Нажимают "Фиксировать" (или фиксировать и отправить), и выполняется изменение версии, к версии приписывается _RC1 сохраняется файл, добавляется в индекс, и уже потом выполняется фиксация.
При следующей фиксации если в конце версии уже есть _RC то к цифре в конце добавляем +1, а если нету то снова пишем _RC1
было бы хорошо что бы кто то реализовал такую штуку...
Или если приям в момент фиксации нельзя, то хотя бы кнопкой отдельной на понели Git

[DitriXNew]

Ага. Брать четвертую пару как короткий хешь коммита. Тогда одни плюсы прям будут :) и коммитить чаще будут и искать проще :)

[DitriXNew]

Но да. Задача не тривиальная.

[nguninb]

Получается такое summary на обсуждение:

Версия сборки проекта конфигурации/расширения конфигурации

- Ручное поднятие версий через кнопку контекстного меню, кнопку панели и прочее

• не нулевой шанс забыть забыть выполнить действие

- Инициировать поднятие версий при сохранении метаданных

• У любителей часто сохраняться потенциально может появиться 100500 версий.
• Если надо одним проектом работают несколько разработчиков, у каждого разработчика будет своя нумерация версий(?).
• При модификации тиражных решений не подходит, по причине пересечения с версией разработчика тиражного решения.
• При модификации решений на БСП необходимо также поднимать версию в модуле подсистемы.

- Поднимать версию при commit

• Использование git не является обязательным при разработке
• При отмене commit'a изменения версии не возвращаются?
• (рассмотреть процесс групповой разработки с учетом Pull/Merge requests)

- Поднимать версию при выгрузке в XML

• Проблемы синхронизации версии при групповой разработке

Проект внешней обработки

• В контексте БСП версия определяется в параметрах регистрации.
• (где логика версии обработки используется во внутренних механизмах БСП?)
• ?

Проект внешнего отчета

• То же что и с внешней обработкой

[RedMammoth]

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

Для проектов конфигурации и расширения номер может хранится в реквизите "Версия" объекта Конфигурация, также номер может хранится в коде (например, модуль ОбновлениеИнформационнойБазыХХХ, стоит учесть, что номер иногда выносят в функцию другого модуля).
Для проектов обработок и отчетов номер может хранится только в коде (теоретически в файлах, например макет).

Есть сценарий, когда общий номер хранится в нескольких местах, например, разработка библиотеки, в таких случаях номер проставляется и в свойство конфигурации и в модуль ОбновлениеИнформационнойБазы библиотеки.
Я не сталкивался, но если существует практика разработки двух библиотек в одном проекте, то может быть несколько мест хранения, причем для каждого места свой нумератор.

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

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

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

[RedMammoth]

Единственное, если мы будем поднимать номер при фиксации коммита, то файлы, в которых изменился номер тоже будут индексироваться в данном коммите, это может вызвать вопросы, особенно если разработчик этого не увидит (возникнет ситуация, что разработчик выполняет фиксацию, своими глазами видит, что в его коммите есть только Объект1 и Объект2, потом заходит в панель история и видит, что в этом коммите дополнительно появились еще файлы, в которых произошла вставка нового номера )

[RedMammoth]

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

[marmyshev]

Возможно, следует сделать поддержку авто-подстановки SNAPSHOT версии (квалификатора) при сборке продукта

Для чего используются:

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

Связанная задача по стандарту: 1C-Company/v8-code-style#109

SemVer в контексте 1С:

1. Major DB (редакция) - совместимость БД для переноса данных обновлением
2. Major (подредакция) - функциональная совместимость (идеологически)
3. Minor (версия) - новая функциональность полностью совместимая с предыдущей версией (расширение функциональности)
4. Patch (сборка) - исправления ошибок
5. Snapshot/Qualifier (???) - квалификатор момента сборки.

Обычно, в других системах (Java, python) Квалификатор не хранится в исходниках, заполняется при сборке.

В месте где необходимо заполнять квалификатор сборки указывается какой-то place-holder типа SNAPSHOT, ${snapshot} или подобное.