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

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

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

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

Ответ 1

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

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

Ответ 2

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

http://semver.org/

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

Ответ 3

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

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

Ответ 4

Прочитав много статей /QAs/FAQs/books, я стал думать что [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, betastrong > , build 23545

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

Ответ 5

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

Учтите, что объявление для Git 1.9 (Januaury 2014):

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

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

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

Следующий кандидат будет v1.9.0-rc3, а не v1.9-rc3;

Первый релиз обслуживания для v1.9.0 будет v1.9.1 (и Nth one be v1.9.N); и

Выпуск функции после версии v.1.9.0 будет либо v1.10.0, либо v2.0.0, в зависимости от того, насколько велика переменная, на которую мы смотрим.