New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Автопроставление (авто-поднятие) версий сборки/проекта #32
Comments
а где ты предлагаешь хранить версию для внешних обработок? |
Для расширений и конфигурации - совсем не проблема сделать авто-подъем версии. Вопрос - в какой момент менять версию? судя по проблемам которы ты описываешь - надо перед каждой заливкой в ИБ менять (т.е. перед каждым экспортом в xml) всё остально (шаблоны, файлы и т.д.) - вроде нет сложностей сделать. Кто бы захотел сделать! ;) Есть желающие? |
А то надоело когда разрабы делают что то, версию не поднимают, кидают клиентам, и клиент пишет тикет, типо - вот в такой версии. А разраб типо - ну я там только одну строку добавил, и забыл версию поменять :) А всех в контур не закинешь, вот и мучаешься. Но последняя капля - это эти гребанные кеши :( |
Всё-таки, это не понятно, как ожидается чтобы система работала. Например. Если при загрузке в ИБ - вот 100500 раз запустил отладку - получишь +100500 номеров в версии. Если ручное действие по инкриментации - то будут так же забывать. |
Менять версию при Фиксации коммита. |
Ага. Брать четвертую пару как короткий хешь коммита. Тогда одни плюсы прям будут :) и коммитить чаще будут и искать проще :) |
Но да. Задача не тривиальная. |
Получается такое summary на обсуждение: Версия сборки проекта конфигурации/расширения конфигурации - Ручное поднятие версий через кнопку контекстного меню, кнопку панели и прочее
- Инициировать поднятие версий при сохранении метаданных
- Поднимать версию при commit
- Поднимать версию при выгрузке в XML
Проект внешней обработки
Проект внешнего отчета
|
На текущий момент у нас есть четыре вида проектов: конфигурация, расширение, отчеты и обработки. С проектами в одном репозитории часто располагают дополнительные данные: документацию, тесты, правила обмена и т.д. - возможно там тоже хотелось бы контролировать номер (может быть не сборки, но редакцию, версию точно) Для проектов конфигурации и расширения номер может хранится в реквизите "Версия" объекта Конфигурация, также номер может хранится в коде (например, модуль ОбновлениеИнформационнойБазыХХХ, стоит учесть, что номер иногда выносят в функцию другого модуля). Есть сценарий, когда общий номер хранится в нескольких местах, например, разработка библиотеки, в таких случаях номер проставляется и в свойство конфигурации и в модуль ОбновлениеИнформационнойБазы библиотеки. Мне кажется версионирование проекта в гит полезно даже при одиночной разработке, поэтому фиксация коммита самое подходящее событие для поднятия номера сборки. Но соглашусь, гит не обязателен, поэтому предлагаю для пользователей не использующих его пока оставить только ручное поднятие. Резюмируя, я думаю, что в проекте нужно иметь возможность хранить несколько нумераторов. Нумераторам следует дать человеко читаемое имя и комментарий. К каждому нумератору должна быть возможность привязать несколько мест вставки в код/реквизиты/файлы проекта. Для плагина следует предусмотреть программный интерфейс/точки расширения, позволяющие другим плагинам увеличивать нумератор, в самом плагине пока предусмотреть только поднятие номера сборки по фиксации коммита (причем, если у нас будет несколько нумераторов, то возможно потребуется не просто следить за фиксацией коммита, а за тем, к какой подсистеме относятся измененные в коммите объекты) и ручное поднятие. На счет групповой разработки, если я не ошибаюсь, то при одновременном изменении версий у разных разработчиков , при мерже будет конфликт, поэтому сохранение работы логики обработчиков обновления или еще каких-нибудь механизмов, завязанных на версиях, будет лежать на ответственности разработчика, выполняющего мерж. |
Единственное, если мы будем поднимать номер при фиксации коммита, то файлы, в которых изменился номер тоже будут индексироваться в данном коммите, это может вызвать вопросы, особенно если разработчик этого не увидит (возникнет ситуация, что разработчик выполняет фиксацию, своими глазами видит, что в его коммите есть только Объект1 и Объект2, потом заходит в панель история и видит, что в этом коммите дополнительно появились еще файлы, в которых произошла вставка нового номера ) |
Может быть стоит для нумератора добавить состояние, поднимался ли он. Изначально состояние Ложь. При первой модификации проекта идет увеличение номера и состояние нумератора переходит в Истину. Если происходит фиксация коммита, то нумератору снова возвращается статус Ложь и идет ожидание следующей модификации проекта. В таком варианте реализации нужно подумать, как вернуть номер на место, если разработчик отменил свои изменения (может как то можно проверять, при модификации проекта, есть ли кроме изменений который сделал наш плагин другие неиндексированные изменения, если нет, то откатывать номер) и как быть, если при фиксации коммита разработчик не индексировал файлы, в которые проставился новый номер (думаю в таком случае можно оставить на совести разработчика) |
Возможно, следует сделать поддержку авто-подстановки SNAPSHOT версии (квалификатора) при сборке продукта Для чего используются:
Связанная задача по стандарту: 1C-Company/v8-code-style#109 SemVer в контексте 1С:
Обычно, в других системах (Java, python) Квалификатор не хранится в исходниках, заполняется при сборке. В месте где необходимо заполнять квалификатор сборки указывается какой-то place-holder типа SNAPSHOT, ${snapshot} или подобное. |
Доброе.
Есть такое предложение к плагину - сделать плагин с автоподстановкой новой версии.
Т.е. я указываю некий шаблон подстановки, и путь к файлу. ЕДТ когда собирает внешнюю обработку или обновляет конфу - поднимает версию сборки автоматом.
Для чего? Ответ один и простой, точнее 2:
The text was updated successfully, but these errors were encountered: