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

107

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

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

Ответы:

45

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

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

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

Майк Б
источник
1
Это имеет тенденцию следовать шаблону, который я видел, успешно использовался во многих проектах, больших или малых. Это очень эффективно.
luis.espinal
1
Как / должен "номер сборки" относиться к "идентификатору набора изменений (хешу)"? Это часть хэша, инкремент или что-то еще?
Джейс Браунинг
@Jace, где я работаю, мы используем Mercurial и отключаем номер ревизии. Мы только когда-либо нажимаем на / извлекаем из одного репозитория, поэтому номер не является уникальным для конкретной проверки. Затем мы имеем [major]. [Minor]. [Changeset] соответственно (хотя старшие и второстепенные цифры часто являются скорее маркетинговыми, чем показательными для прогресса со времени последней версии).
Вай Ха Ли
Если вы вызываете ToString () в структуре версии .NET, сборка будет 3-м номером, а не ревизией. Как вы можете видеть из этого сценария PowerShell:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
Джоэл МакБет
Означает ли "номер сборки", что это просто незначительные изменения, такие как исправление ошибок? Должны ли какие-либо новые функциональные возможности хотя бы получить свой собственный номер редакции?
Кайл Делани
90

Семантическое управление версиями ( http://semver.org/ ) заслуживает упоминания здесь. Это публичная спецификация для схемы управления версиями в форме [Major].[Minor].[Patch]. Мотивация для этой схемы заключается в сообщении смысла с номером версии.

М. Дадли
источник
Удивлен, это не получает больше любви.
Марк Канлас
Я немного опоздал на вечеринку ... Я добавил этот ответ через 9 месяцев после первоначального вопроса. ;-)
М. Дадли
Похоже, что это работает так же, как политика RubyGems Rational Versioning, о которой я упоминал ниже, только лучше формализовано.
Кен Блум
@MarkCanlas не получает больше любви, потому что он придает конкретные идеи тому, что составляет основной / минорный / патч релиз В нем говорится об API, что довольно ... странно
Рудольф Олах
5
SemVer предназначен для API-интерфейсов управления версиями, а не для программного обеспечения, ориентированного на пользователя: «Программное обеспечение, использующее семантическое управление версиями, ДОЛЖНО объявлять общедоступный API». Технически, вы не можете использовать SemVer без публичного API. Тем не менее, может иметь смысл принять нечто похожее на SemVer для управления версиями пользовательских приложений.
Ajedi32
33

Я не использую это, но я видел, и это интересная структура:

Year.Month.Day.Build

Сам объяснил.

Maniero
источник
4
И вы всегда знаете, насколько свеж ваш код ..! :)
Липис
3
это также похоже на номера версий Ubuntu. Они делают year.month Примеры: 10.04 и 10.10
Брэд Купит
5
Стоит отметить, что это хорошо работает только для системы, которая либо не имеет проблем с совместимостью (веб-сайт), либо по своей сути всегда имеет несовместимость (выпуск Ubuntu).
jkerian
1
@jkerian, почему совместимость имеет значение для этого?
AviD
12
@AviD: я немного озадачен, почему вы спрашиваете об этом, так как почти каждый ответ на этот вопрос показывает версии систем, которые включают информацию о совместимости. Ваш выбор зависит от того, какую информацию вы хотите записать с вашими номерами версий. Для моих целей дата в принципе не имеет никакого значения (просто начинать с v1 и увеличивать каждую сборку было бы улучшением). Вы когда-нибудь ветвились? Вы когда-нибудь выпускали "новый патч на старый код", выпуская "новую версию"? Но для чего-то вроде веб-сайта или операционной системы система, основанная на дате, кажется вполне подходящей.
jkerian
13

Я пытаюсь использовать политику RubyGems Rational Versioning, в которой:

  • Номер основной версии увеличивается, если двоичная совместимость нарушена
  • Дополнительный номер версии увеличивается при добавлении новой функциональности
  • Изменен номер сборки для исправления ошибок.
Кен Блум
источник
2
По существу это называется семантическим версионированием
Патрис М.
2
@PatriceM. Спасибо, что поделились этой ссылкой. semver.org не существовало, когда я написал этот ответ.
Кен Блум,
10

Вот очень детальный подход к нумерации версий:

  • 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должен быть изменен в соответствии с изменениями в архитектуре или изменениями основных идей и принципов ее работы / функционирования.
  • Не иметь контроля над своей кодовой базой . Вероятно, есть только одна ветвь (ствол), и она используется для всего. Что лично я не считаю правильным, так как это побуждает кодовую базу превращаться в одну большую мусорную свалку.

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

чередующееся
источник
Первая ссылка вниз ...............
Pacerier
8

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

[болезненное состояние] [аллитеративное имя животного]

Которые дали такие названия, как « Хромая минога », « Раненый вомбат » и « Астматический муравьед ».

Удостоверьтесь, что если это действительно классное имя, оно не просочится вашим клиентам.

Джесси С. Слайсер
источник
2
Похоже, неэффективное использование времени и энергии .............
Pacerier
10
Так что оставил этот комментарий, но это не остановило вас.
Джесси С. Slicer
Это на целую величину меньше ......
Pacerier
7

Generation.Version.Revision.Build (9.99.999.9999)

Поколение редко меняется. Только большой поворот на продукт: DOS -> Windows, полный реинжиниринг.

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

Пересмотр часто делается (незначительные функции и исправление ошибок).

Сборка это внутренняя информация.

Maniero
источник
Хорошая идея. Откуда вы взяли идею «поколения»?
Pacerier
6

git describeобеспечивает хорошее расширение для любого соглашения о нумерации, которое вы выбрали. Это достаточно просто внедрить в процесс сборки / упаковки / развертывания.

Предположим, вы назвали свои версии релизов с тегами ABC (major.minor.maintenance). git describeв данном коммите найдет самого последнего помеченного предка коммита, затем отметьте количество коммитов с тех пор и сокращенный SHA1 коммита:

1.2.3-164-g6f10c

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

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

Cascabel
источник
2

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, добавленными для этих особых случаев.
GrandmasterB
источник
2

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

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

major.minor.build.revision

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

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

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

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

Джеффри Кэмерон
источник
1

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

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

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

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

JBRWilkinson
источник
1

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

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

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

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

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

Таким образом, если кто-то использует, скажем, версию, 1.5.3он может сразу сказать, что он может обновиться, чтобы 1.5.4получить исправления, что 1.6.0добавит функциональность и что он не должен обновляться 2.0.0(по крайней мере, без обработки изменения).

Кит
источник
Semver работает только для API. Не продукты.
Pacerier
@Pacerier, не могли бы вы объяснить, почему?
Кит
@Pacerier, это не значит, что вы не можете использовать этот шаблон для нумерации версий.
Кит
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).

barjak
источник