Подходят ли разные соглашения об именах версий для разных проектов? Что вы используете и почему?
Лично я предпочитаю номер сборки в шестнадцатеричном формате (например, 11BCF), его следует увеличивать очень регулярно. А затем для клиентов простой трехзначный номер версии, т.е. 1.1.3.
1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.
$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
Семантическое управление версиями ( http://semver.org/ ) заслуживает упоминания здесь. Это публичная спецификация для схемы управления версиями в форме
[Major].[Minor].[Patch]
. Мотивация для этой схемы заключается в сообщении смысла с номером версии.источник
Я не использую это, но я видел, и это интересная структура:
Year.Month.Day.Build
Сам объяснил.
источник
Я пытаюсь использовать политику RubyGems Rational Versioning, в которой:
источник
Вот очень детальный подход к нумерации версий:
N.x.K
гдеN
иK
целые числа. Примеры:1.x.0
,5.x.1
,10.x.33
. Используется для промежуточных сборок .N.M.K
, ГдеN
,M
иK
целые числа. Примеры:1.0.0
,5.3.1
,10.22.33
. Используется для релизов .N.x.x
гдеN
целое число Пример:1.x.x
. Используется для поддержки филиалов .N.M.x
гдеN
иM
целые числа. Пример:1.0.x
. Используется для выпуска веток .Вот иллюстрация для простой иллюстрации подхода нумерации версий:
PA
означает пре-альфаA
означает альфаB
означает бетаAR
означает альфа-релизBR
означает бета-релизRC
означает релиз-кандидатST
означает стабильныйПреимущества такого подхода к нумерации версий следующие:
N.x.K
) и release (N.M.K
). Выпуск означает, что часть программного обеспечения с полным номером версии (N.M.K
) прошла некоторый процесс управления качеством в компании-поставщике / организации / команде.Существует также более сложная схема, подробно представляющая подход к управлению версиями. Также вы можете найти полезные слайды презентации, описывающие переход к подходу управления версиями и приложение SCMFViz, иллюстрирующее основные принципы подхода нумерации версий. Презентационные слайды также объясняют, почему важно придерживаться одного и того же подхода к управлению версиями на протяжении всей жизни программного проекта.
Лично мое отношение к использованию версии даты вместо реальных номеров версий предполагает, что разработчики программного обеспечения с устаревшими версиями:
N
inN.M.K
) отвечает как за архитектурное решение, так и за основной принцип приложения. Номер основной версииN
должен быть изменен в соответствии с изменениями в архитектуре или изменениями основных идей и принципов ее работы / функционирования.Этот подход может показаться немного спорным, но я считаю, что это наиболее простой способ присвоения программам соответствующих номеров версий.
источник
Для каждой основной версии, которую вы выпускаете, весьма обычно иметь рабочую версию, которую вы называете внутри. Например, на моей последней работе мы ссылались на основную версию со следующим соглашением об именах в стиле Ubuntu:
[болезненное состояние] [аллитеративное имя животного]
Которые дали такие названия, как « Хромая минога », « Раненый вомбат » и « Астматический муравьед ».
Удостоверьтесь, что если это действительно классное имя, оно не просочится вашим клиентам.
источник
Generation.Version.Revision.Build (9.99.999.9999)
Поколение редко меняется. Только большой поворот на продукт: DOS -> Windows, полный реинжиниринг.
Версия для больших несовместимых изменений, новой функциональности, изменений некоторых специфических парадигм в программном обеспечении и т. Д.
Пересмотр часто делается (незначительные функции и исправление ошибок).
Сборка это внутренняя информация.
источник
git describe
обеспечивает хорошее расширение для любого соглашения о нумерации, которое вы выбрали. Это достаточно просто внедрить в процесс сборки / упаковки / развертывания.Предположим, вы назвали свои версии релизов с тегами ABC (major.minor.maintenance).
git describe
в данном коммите найдет самого последнего помеченного предка коммита, затем отметьте количество коммитов с тех пор и сокращенный SHA1 коммита:Если вы на самом деле на одной из версий, конечно, вы просто получите тег (1.2.3).
Это дает приятное преимущество, позволяя вам точно знать , из какого источника вы собрали, при этом не нужно нумеровать каждую сборку самостоятельно.
источник
Major.Minor.Public (сборка) [альфа / бета / пробная версия], например "4.08c (1290)"
источник
Я предпочитаю номера версий, которые присваивают некоторый смысловой смысл. Если вы можете использовать номер версии для отслеживания ошибок, сообщенных в конкретной версии, в отношении изменений, произошедших в исходном коде (и в вашей системе управления активностью), то вы, вероятно, используете правильный метод.
Я использую .NET, поэтому я застрял с системой нумерации версий .NET, но я пытаюсь придать числам смысловой смысл, так что
major.minor.build.revision
Мы всегда следим за тем, чтобы номер версии каким-то образом был виден (наши пакетные консольные программы выводятся на консоль и в файл журнала, а веб-приложения - в строке меню вверху)
Таким образом, если клиенты сообщают о проблемах, мы можем использовать номер версии, чтобы отслеживать, используют ли они последнюю версию и сколько у нас проблем с конкретными версиями.
Все дело в прослеживаемости!
источник
Мы используем Major.Minor.Build # .YYMMDD [суффикс], так как мы обычно делаем только одну производственную сборку в любой конкретный день (но используем суффикс ab / c / d, если их больше одного), а YYMMDD дает пользователям / клиентам / управлению указание возраста сборки, где 6.3.1389 нет.
Основные номера увеличиваются с существенными характеристиками продукта (оплачено).
Незначительные числа увеличиваются с исправлениями / улучшениями (бесплатное обновление).
Сборка всегда увеличивается; не все строит корабли, поэтому это не линейная прогрессия.
источник
Номера версий должны иметь достаточно информации, чтобы избежать конфликтов и исправить ошибку в проблемах неправильного типа выпуска, но не должны содержать дополнительную информацию, которая не имеет отношения к делу.
Например, если вы используете дату, клиенты могут сказать, что у них более старая версия, а исправления для старых версий могут иметь запутанные версии.
Мне лично нравится семантическая версия :
Major
.Minor
,Patch
Patch
увеличивается каждый раз, когда вы выпускаете сборку.Minor
увеличивается каждый раз, когда добавляется обратно совместимая функциональность.Major
увеличивается, когда новая функциональность не имеет обратной совместимости.Major
== 0 вы находитесь в альфа / пре-релиз.Major
> = 1 ваши публичные релизы.1.5.3
он может сразу сказать, что он может обновиться, чтобы1.5.4
получить исправления, что1.6.0
добавит функциональность и что он не должен обновляться2.0.0
(по крайней мере, без обработки изменения).источник
X.Y.Z
это наш внутренний номер версии.X.Y
является общедоступным номером версии, который имеет значение для наших клиентов. КогдаX.Y.Z
версия становится общедоступной, ее никогда не будетX.Y.(Z+1)
: общедоступная версия всегда будет последней из серии.X
увеличивается при выпуске основной версии.Y
используется для веток обслуживания этих основных выпусков, только для исправления ошибок.Z
используется внутри, и не имеет фиксированного значения. До сих пор я создаю новуюZ
версию, когда считаю, что приложение имеет набор функций, которые интересно показать не разработчикам, и относительно стабильно. Таким образом, я могу показать демо «последней известной хорошей версии» приложения, когда кто-то спросит. В ближайшем будущем я планирую использоватьZ
номера версий для обозначения «цели» функций в нашем багтрекере.В качестве примечания мы используем maven (с
release
командой) для увеличения номера версии. Таким образом, естьX.Y.Z-SNAPSHOT
версии (которые указывают любую версию междуX.Y.(Z-1)
иX.Y.Z
).источник