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

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

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

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

источник

2010-01-12 deamon

Будет http://stackoverflow.com/questions/1889615/version-numbering-basics help? – VonC

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

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

источник

2010-01-12 11:27:55 Tobu

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

http://semver.org/

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

источник

2010-01-12 11:37:37 sixohsix

The - - схема от Maven, похоже, не соответствует точно рекомендациям semver.org. semver.org: «Специальный номер версии МОЖЕТ быть обозначен путем добавления произвольной строки ** сразу после ** версии исправления. Строка ДОЛЖНА состоять только из буквенно-цифровых символов плюс тире [0-9A-Za-z-] и ** ДОЛЖЕН начинаться с альфа-символа [A-Za-z] **. " – deamon

@deamon semver.org, вероятно, изменил его много лет назад, но для записи он теперь соответствует схеме maven: «Предварительно выпуская версия МОЖЕТ быть обозначена добавлением дефиса и серии разделенных точками идентификаторов сразу после версии патча. ДОЛЖЕН содержать только буквенно-цифровые символы ASCII и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Числовые идентификаторы НЕ ДОЛЖНЫ включать в себя начальные нули. » – Kapep

@kapep: Форматы все еще не полностью совместимы, поскольку алгоритм сравнения из semver намного сложнее, чем использует Maven. Но если вы придерживаетесь только «-RC1», «-RC2» или аналогичного, вы должны быть в порядке. – sleske

После прочтения многих статей/ЧАС/Часто задаваемые вопросы/книг я стал думать , что [MAJOR]. [МАЛЫЙ]. [REV] является наиболее полезным версиями схемы для описания совместимости версии проекта (управление версиями схемой для разработчиков, не для маркетинга).

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

НЕЗНАЧИТЕЛЬНЫХ изменений имеют обратную совместимость. Пометьте знакомство с новыми функциями .

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

Этой версий схемы вдохновленного LIBTOOL управления версиями семантики и статьи:

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

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

Hello app v2.6.34 для Национального банка, 2011-05-03, бета, построить

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

источник

2011-10-11 18:24:00 gavenkoa

Чисто для полноты, я упомянул old Apple standard for version numbers. Это выглядит как основная версия. недействительная версия. ошибка ошибка. этап. неопубликованная версия. Этап представляет собой код, взяты из набора д (разработка), (альфа), б (бета), или Ь (конечный корабль клиент - более или менее такой же релиз-кандидат, я думаю) ,

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

Итак, первая версия чего-то может быть 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, и будет много радости.

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

источник

2012-04-27 16:09:34

Чисто для полноты (:-)), я хотел бы указать, что ИМХО, требующее отдельных сборок для каждого этапа (что подразумевает эта схема), не является хорошей идеей. По крайней мере, сборки для окончательного QA/тестирования должны работать без изменений. Любые требуемые различия в поведении должны вводиться через конфигурацию. См. [Разделить сборку «debug» и «release»?] (Http://stackoverflow.com/questions/420343/separate-debug-and-release-builds). – sleske

@sleske Я не думаю, что это подразумевает отдельные сборки для каждого этапа. Если вы находитесь на стадии бета-тестирования, вы должны создать 1.2.3b4 в dev, поместите это через CI, получите QA, чтобы одобрить его, сделать UAT, а затем перевести его на бета-тестеры, используя все те же бинарные файлы. Скорее, это подразумевает, что в любой момент вы знаете, как далеко может развиться сборка, поэтому вы знаете, когда будете считать, что она будет использоваться только в разработке, отправлена бета-тестерам, выпущена и т. Д. На переходах есть некоторое дублирование , например, если 1.2.3b10 проходит бета-тестирование, тот же код, вероятно, станет 1.2.3fc1, что не является идеальным. –

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

Считают, что announcement for Git 1.9 (Januaury 2014):

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

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

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

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

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

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

источник

2014-02-04 07:30:33 VonC

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

ответ

Смежные вопросы