Почему build.number является «злоупотреблением» семантическим версионированием?

Я объяснял предлагаемую систему сборки (Gradle / Artifactory / Jenkins / Chef) одному из наших старших архитекторов, и он сделал мне комментарий, с которым я как- то не согласен, но у меня недостаточно опыта, чтобы реально взвесить.

Этот проект создает библиотеку Java (JAR) в качестве артефакта для повторного использования другими командами. Для управления версиями я бы хотел использовать семантический подход:

<major>.<minor>.<patch>

Где patchуказывает на исправление ошибок / аварийных ситуаций, minorуказывает на обратно-совместимые выпуски и majorуказывает либо на массивный рефакторинг API, и / или обратно-несовместимые изменения.

Что касается доставки, то вот чего я хочу: разработчик фиксирует некоторый код; это запускает сборку в среде QA / TEST. Некоторые тесты проводятся (некоторые автоматизированы, некоторые ручные). Если все тесты пройдены, то производственная сборка публикует JAR для нашего внутреннего репозитория. К этому моменту JAR должен быть версионирован должным образом, и я подумал о том, чтобы использовать тот, build.numberкоторый автоматически генерируется и предоставляется нашим инструментом CI, в качестве номера патча.

Таким образом, управление версиями будет:

<major>.<minor>.<build.number>

Опять же, где build.numberпредоставляется инструмент CI.

Архитектор отклонил это, заявив, что использование номера сборки CI было «злоупотреблением» семантическим версионированием.

У меня вопрос: правильно ли это, и если да, то почему? И если нет, то почему?

Ваш номер сборки не будет сброшен до 0, когда младшие и основные версии увеличиваются, это нарушает разделы 7 и 8 спецификации :

Незначительная версия Y (xYz | x> 0) ДОЛЖНА быть увеличена, если в общедоступный API введена новая, обратно совместимая функциональность. Он ДОЛЖЕН быть увеличен, если какая-либо публичная функция API помечена как устаревшая. Это МОЖЕТ быть увеличено, если в частный код будут введены существенные новые функциональные возможности или улучшения. Это МОЖЕТ включать изменения уровня патча. Версия патча ДОЛЖНА быть сброшена на 0 при увеличении младшей версии.

Основная версия X (Xyz | X> 0) ДОЛЖНА быть увеличена, если в общедоступный API будут внесены какие-либо обратные несовместимые изменения. Это МОЖЕТ включать незначительные изменения и изменения уровня патча. Патч и минорная версия ДОЛЖНЫ быть сброшены на 0 при увеличении основной версии.

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

Если вы хотите включить свой номер сборки, вы можете добавить их после +(раздел 10):

Метаданные сборки МОГУТ обозначаться добавлением знака плюс и серии разделенных точками идентификаторов сразу после исправления или предварительной версии. Идентификаторы ДОЛЖНЫ содержать только буквенно-цифровые символы ASCII и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Метаданные сборки ДОЛЖНЫ игнорироваться при определении приоритета версии. Таким образом, две версии, которые отличаются только метаданными сборки, имеют одинаковый приоритет. Примеры: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Одна из причин заключается в том, что для исправления может потребоваться несколько сборок, поэтому, если у вас версия 5.7, и вы хотите установить исправление до 5.7.1, но ваши первые 2 исправления не удастся собрать, когда они будут отправлены в систему CI, вы будете на 5.7.3, прежде чем вы выпустили свой первый патч!

Ответ состоит в том, чтобы просто использовать 4 цифры (как это обычно бывает в системах Microsoft). Четвёртый номер сборки и используется «только для информации». Обычно люди помещают туда номер версии репозитория (если они используют SVN или TFS или аналогичный), что очень удобно, поскольку вы можете проверить, какой именно коммит был использован для сборки двоичных файлов. Если у вас нет такой вещи, то номер сборки CI является разумным приближением (поскольку вы надеетесь, что ваша система CI сможет запомнить номера сборок и связать их с историей репо, но вы не зависите от CI система запоминает их - вы никогда не сможете удалить старые сборки).

Стоит отметить, что схема Microsoft для управления версиями использует третью позицию для номеров сборок. Chrome использует только 1 номер. Ubuntu использует дату. Не существует «стандарта» для использования , за исключением того, что все числа должны увеличиваться.