Какую схему нумерации версий использовать?

Question

Я ищу схему нумерации версий, которая выражает степень изменений, особенно совместимость.

Apache APR , например, использовать хорошо известную схему нумерации версий

<major>.<minor>.<patch>
example: 4.5.11

Maven предлагает похожую, но более детальную схему:

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Где определяется схема управления версиями Maven? Существуют ли соглашения для квалификатора и номера сборки? Возможно, это плохая идея использовать Maven, но не следовать схеме версий Maven ...

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

Answer 1

Вот текущий алгоритм сравнения версий Maven и обсуждение его. Пока версии только растут, а все поля, кроме номера сборки, обновляются вручную, все в порядке. Классификаторы работают следующим образом: если один является префиксом другого, более длинный - старше. В противном случае они сравниваются по алфавиту. Используйте их для предварительных релизов.

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

Answer 2

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

http://semver.org/

Короче говоря, это <major>.<minor>.<patch><anything_else>, и вы можете добавить дополнительные правила к любой другой части, которая вам подходит. например. -<qualifier>-<build_number>.

Answer 3

Чисто для полноты я упомяну старый стандарт Apple для номеров версий . Это выглядит как основная версия . минорная версия . версия ошибки . этап * * 1 010. не выпускаемая версия . Этап - это код, полученный из набора d (разработка), a (альфа), b (бета) или fc ( конечный клиент - более или менее такой же, как и кандидат на релиз, я думаю).

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

Итак, первая версия чего-то может быть 1.0.0. Возможно, вы выпустили исправление как 1.0.1, новую версию (с большим количеством функций) как 1.1 и переписали или обновили до 2.0. Если вы хотите перейти к 2.0.1, вы можете начать с 2.0.1d1, 2.0.1d2, 2.0.1d153 или чего-то еще, что вам потребовалось, затем отправить 2.0.1a1 в QA и после того, как они утвердят 2.0.1a37. , отправьте 2.0.1b1 нескольким желающим игрокам, затем после того, как 2.0.1b9 прожил неделю в поле, сожгите 2.0.1fc1 и начните получать подписи. Когда 2.0.1fc17 будет достаточно, он станет 2.0.1, и будет много радости.

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

Answer 4

Прочитав много статей / вопросов / ответов / книг / книг, я начинаю думать что [MAJOR]. [MINOR]. [REV] является наиболее полезной схемой управления версиями для описать совместимость между версией проекта (схема управления версиями для разработчика, а не для маркетинга).

ОСНОВНЫЕ изменения обратно несовместимы и требуют изменения имя проекта, путь к файлам, GUID и т. д.

MINOR изменения обратно совместимы. Отметить введение нового особенности.

REV для безопасности / исправления ошибок. Обратная и прямая совместимость.

Эта схема управления версиями, вдохновленная libtool версиями семантики и статьями:

http://www106.pair.com/rhp/parallel.html

ПРИМЕЧАНИЕ: Я также рекомендую предоставить build / date / custom / quality в качестве дополнительной информации (build номер, дата сборки, имя клиента, качество выпуска):

Привет приложение v2.6.34 для Национальный банк , 2011-05-03 , бета , сборка 23545

Но эта информация не информация о версиях!

Answer 5

Обратите внимание, что схема номеров версий (например, x.y.0 против x.y) может быть ограничена внешними факторами.

Считайте, что объявление для Git 1.9 (январь 2014) :

Кандидат на выпуск Git v1.9-rc2 теперь доступен для тестирования в обычных местах.

Я слышал слухи о том, что различным сторонним инструментам не нравятся двузначные номера версий (например, "Git 2.0") , и я начал бить влево и вправо когда пользователи устанавливают v1.9-rc1.
Хотя соблазнительно смеяться над ними из-за их небрежного предположения, я также практичен и не против позвонить в следующий выпуск v1.9.0, чтобы помочь им.

Если мы пойдем по этому маршруту (и я склонен идти по этому маршруту в данный момент), схема управления версиями будет:

• Следующим кандидатом на выпуск будет v1.9.0-rc3, а не v1.9-rc3;
• Первый выпуск поддержки для v1.9.0 будет v1.9.1 (а N-й будет v1.9.N); и
• Релиз функции после v1.9.0 будет либо v1.10.0, либо v2.0.0, в зависимости от того, насколько большим будет скачок функции.