Почему 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 было «злоупотреблением» семантическим версионированием.

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

— herpylderp
источник

Ответы:

Ваш номер сборки не будет сброшен до 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.

— отстой
источник

Быстрый контроль @Residuum (и BTW +1 для ответа): номера версий всегда должны быть получены вручную тогда? Если нет, какие инструменты можно использовать вместо CI / номер сборки?

— herpylderp

@herpylderp нисколько, «спецификация» Тома Престона-Вернера - только его мнение, у множества других компаний есть различные (вообще очень похожие друг на друга) стандарты. В большинстве из них автоматически генерируемый номер является частью версии. Использовать номер сборки CI - разумная вещь.

— gbjbaanb

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

— KeithS

Что касается меня, я просто использую [major]. [Minor]. [Revision]. [SVN-Version] для DLL и [major]. [Minor]. [SVN-Version] для инсталляторов. Номер сборки CI предназначен только для внутреннего использования, чтобы показать, где неудачная сборка могла быть повторно запущена на той же самой кодовой базе после изменения среды CI (установка сертификата ключа, добавление общих библиотек в GAC и т. Д.).

— KeithS

@gbjbaanb и др .: В каждой дискуссии о «семантическом версионировании», частью которой я был, было определение из semver.org . Поищите в сети «семантическое управление версиями», и, по крайней мере, на первой странице появятся плюсы и минусы определения из semver.org . Вы можете использовать свои собственные схемы управления версиями, но не называйте это семантическим контролем версий, так как этот термин четко определен.

— Residuum

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

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

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

— gbjbaanb
источник

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

— Довал

Даже это не работает в этой области, например, в версии Microsoft NuGet для управления версиями используется semver неработающим способом (с использованием стиля предварительной версии для номеров сборок ), а в Ruby используется major.minor.teeny.patch . В любом случае, так как номер сборки может быть частью semver, архитектор говорил с тобой (хотя по общему признанию, он должен быть + build, а не в 3-й позиции).

— gbjbaanb

Насколько я могу судить, спецификация SemVer 2.0 относится к 2013 году, а версия 1.0 - к 2012 году. Вероятно, NuGet и Ruby занимались своими делами до появления спецификации. Не то, чтобы спецификация SemVer была новой; это просто формализует то, что люди уже делали, поэтому мы все можем наконец договориться об одном способе сделать это вместо дюжины вариантов.

— Довал

«у вас версия 5.7, и вы хотите исправить ее до 5.7.1, но ваши первые 2 исправления не удастся собрать, когда они будут отправлены в систему CI, тогда вы будете на 5.7.3 до того, как выпустите свой первый патч !» хорошо, но что с того? Я не помню, чтобы в Семвере говорилось, что цифры не должны пропускаться.

— Энди,