Откуда номер версии?

У меня есть система контроля версий (например, Subversion), и теперь я хотел бы настроить процесс сборки. Теперь мне нужно создать номер версии и вставить его в систему. А откуда номер версии берется и влезает? Предположим, я хочу использовать эту общую схему ‹major>. ‹Minor>. ‹Bugfix / revision>. Должен ли я передать номер сценарию сборки? Или мне следует передать такие аргументы, как УвеличитьМажор, УвеличитьМинор, УвеличитьРевизию? Или вы порекомендуете создать ветку с номером, который будет обнаружен скриптом сборки?

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

В моем случае у меня есть несколько файлов php, которые я хотел бы заархивировать, но прежде, чем мне нужно будет вставить некоторые номера версий в файл php.

Я отредактировал этот пост, чтобы сделать свой запрос более ясным:

Я не использую Subversion, это просто пример. И я не хочу обсуждать схему нумерации версий.

Представьте, что я хочу создать версию 3.5.0 или 3.5.1. Могу ли я передать этот номер версии сценарию сборки? Будет ли сценарий создавать ветку в репозитории с этим номером или ожидать, что кто-то уже создал эту ветку? Вручную? Или сценарий сборки будет искать имя ветки (например, «3.5.1») и использовать его для дальнейших задач? И номер версии исходит из моего мозга или он создается автоматически (я предполагаю, что основной / дополнительный номер он исходит из моего маленького мозга, и создается номер версии)? Или вы поместите номер в файл, который может быть вставлен в репозиторий?

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


version-control version-numbering
person robsch    schedule 20.01.2009    source источник

Ответы (5)


arrow_upward
5
arrow_downward

Для подрывной деятельности либо возьмите глобальный номер ревизии и используйте его как номер «сборки», либо, что еще лучше, вообще не полагайтесь на него и управляйте версиями с помощью тегов и / или веток. Основная проблема с глобальной ревизией именно в том, что она глобальна для репо. Он будет увеличиваться, даже если некоторые части репо не изменятся.

ИМХО лучше полностью отделить версии от ревизий репо. У вас есть теги, используйте их.

person Keltia    schedule 20.01.2009
comment
В случае DVCS используйте HASH в качестве идентификатора запроса. Для SVN используйте svnversion -c. - person gavenkoa; 19.08.2011

arrow_upward
2
arrow_downward

согласен со всеми предыдущими об использовании веток и тегов. Кроме того, имена веток и тегов могут быть включены в процесс сборки с помощью некоторых умных сценариев.

Единственный лакомый кусочек, который я хочу добавить, это то, что вы должны скрывать свою ревизию SVN в каждой сборке. Иногда легко вернуться к определенной точке с ревизией, не зная тега или ветки. На 99% тег / ветка достаточно хорош, но ревизия отлично подходит для инкрементальных / внутренних / непрерывных / тестовых сборок.

person basszero    schedule 21.01.2009

arrow_upward
2
arrow_downward

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

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

Версия обычно хранится в файле, который вы обновляете вручную один раз за цикл выпуска. Он регистрируется в правом отделении, а затем остается в покое. Например, основная ветка будет иметь version = "3" в своем файле, первая ревизия в ветке выпуска будет иметь version = "3.5", и, если требуется выпуск патча, вы ответите за него из своей ветки выпуска и установите version = «3.5.1»

person Community    schedule 21.01.2009

arrow_upward
1
arrow_downward

Версия в svn или любой другой системе управления версиями - это не то же самое, что номер версии вашего продукта (или даже номер сборки).

Есть несколько способов принудительно указать номер версии. Обычно в Subversion вы можете создать ветку (или тег, по сути это одно и то же) для сборки, и если это версия выпуска, вы создаете для нее тег, например svn: //my-repo/releases/1.0.0

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

person Jeremy French    schedule 20.01.2009

arrow_upward
0
arrow_downward 

x.y.i.j

Где x - основная версия, y - дополнительная версия, i - номер сборки, j - номер редакции

Major version приращений при основных изменениях (новая архитектура, новый пользовательский интерфейс и т. Д.)

Minor version увеличивается при незначительных изменениях (улучшение производительности, исправление серьезных ошибок и т. Д.),

Build number увеличивается каждый раз, когда вы публикуете публичный выпуск.

Revision number увеличивается каждый раз, когда вы фиксируете изменения в исходном дереве проекта.

Я предпочитаю указывать 0 как номер версии в AssemblyInfo.cs и указывать реальный номер в имени пакета выпуска (foo-1.1.7.110-source.zip)

person abatishchev    schedule 21.01.2009