Какое «соглашение об именах версий» вы используете? [закрыто]

Подходят ли разные соглашения об именах версий для разных проектов? Что вы используете и почему?

Лично я предпочитаю номер сборки в шестнадцатеричном формате (например, 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.

Я редко бываю полностью согласным с Джеффом Этвудом, но я склонен следовать его мнению относительно соглашения о нумерации версий .NET .

(Основная версия). (Малая версия). (Номер редакции). (Номер сборки)

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

Семантическое управление версиями ( 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 означает стабильный

Преимущества такого подхода к нумерации версий следующие:

• Он представляет особенности жизненного цикла разработки гибкого программного обеспечения .
• Он учитывает специфику структуры репозитория исходного кода .
• Это самоочевидно для тех, кто привык к шаблонам. Каждый шаблон представляет разные артефакты. Такие шаблоны могут быть легко проанализированы и использованы для других целей, таких как отслеживание проблем.
• Набор шаблонов управления версиями, базовый для описанного подхода управления версиями, который можно использовать для сбора метрик и планирования .
• Он ориентирован на понятия зрелости и уровня качества . Очень часто такие номера версий, как 1.0.0, назначаются без особой необходимости (когда программное обеспечение находится в глубокой альфа-версии). Представленный подход к нумерации версий позволяет установить несколько уровней зрелости. В простейшем случае он будет иметь только два уровня: промежуточный build ( N.x.K) и release ( N.M.K). Выпуск означает, что часть программного обеспечения с полным номером версии ( N.M.K) прошла некоторый процесс управления качеством в компании-поставщике / организации / команде.
• Это свидетельство гибкой природы как разработки, так и тестирования.
• Поощряет модульный подход к структуре и архитектуре программного обеспечения.

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

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

• Ничего не знаю о жизненном цикле разработки программного обеспечения . Разработка обычно гибкая и итеративная. Подход нумерации версий должен отражать итеративный характер процесса разработки программного обеспечения.
• Не заботьтесь о качестве программного обеспечения . Контроль и обеспечение качества являются гибкими и повторяющимися. Так же, как развитие. И номер версии должен быть свидетельством гибкой и итеративной природы как разработки, так и контроля / обеспечения качества.
• Не заботятся об архитектуре или идее их применения. Основной номер версии ( Nin N.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-164-g6f10c

Если вы на самом деле на одной из версий, конечно, вы просто получите тег (1.2.3).

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

Major.Minor.Public (сборка) [альфа / бета / пробная версия], например "4.08c (1290)"

• Основным номером версии является Major (1, 2, 3 ...)
• Незначительный, являющийся двухзначной минорной версией (01, 02, 03 ...). Обычно цифры десятков увеличиваются при добавлении значительных новых функций, только для исправления ошибок.
• Публичным является публичный выпуск сборки (a, b, c, d, e), который часто отличается от вспомогательной версии, если вспомогательная версия никогда не выпускается как публичное обновление
• build - это фактический номер сборки, за которым следит компилятор.
• с TRIAL, ALPHA, BETA X или RC X, добавленными для этих особых случаев.

Я предпочитаю номера версий, которые присваивают некоторый смысловой смысл. Если вы можете использовать номер версии для отслеживания ошибок, сообщенных в конкретной версии, в отношении изменений, произошедших в исходном коде (и в вашей системе управления активностью), то вы, вероятно, используете правильный метод.

Я использую .NET, поэтому я застрял с системой нумерации версий .NET, но я пытаюсь придать числам смысловой смысл, так что

major.minor.build.revision

• Major = (до проекта)
• несовершеннолетний = (до проекта)
• build = номер сборки от Hudson (вы можете использовать TeamCity или TeamBuild и т. д. здесь)
• Revision = Subversion или базарная ревизия (в зависимости от проекта и того, что он использует)

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

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

Все дело в прослеживаемости!

Мы используем Major.Minor.Build # .YYMMDD [суффикс], так как мы обычно делаем только одну производственную сборку в любой конкретный день (но используем суффикс ab / c / d, если их больше одного), а YYMMDD дает пользователям / клиентам / управлению указание возраста сборки, где 6.3.1389 нет.

Основные номера увеличиваются с существенными характеристиками продукта (оплачено).

Незначительные числа увеличиваются с исправлениями / улучшениями (бесплатное обновление).

Сборка всегда увеличивается; не все строит корабли, поэтому это не линейная прогрессия.

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

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

Мне лично нравится семантическая версия :

• Релизы есть Major. Minor,Patch
• Patch увеличивается каждый раз, когда вы выпускаете сборку.
• Minor увеличивается каждый раз, когда добавляется обратно совместимая функциональность.
• Major увеличивается, когда новая функциональность не имеет обратной совместимости.
• Когда Major== 0 вы находитесь в альфа / пре-релиз. Major> = 1 ваши публичные релизы.
• Нижние числа сбрасываются в 0 при каждом увеличении, поэтому

  1.5.3-> 1.5.4(исправление ошибки) -> 1.6.0(дополнительная функция) -> 2.0.0(критическое изменение)

              1.0.0
                |
              1.0.1
                |
(общедоступный 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (общедоступная 1.1)
                |
(общедоступный 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (общедоступный 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

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).