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

Мой вопрос: это правильно, и если да, то почему? А если нет, почему бы и нет?

31 голос | спросил herpylderp 14 PM00000060000000231 2014, 18:12:02

2 ответа


39

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

  

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

     

Основная версия X (X.y.z | 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 14 PM00000060000000531 2014, 18:15:05
1

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

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

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

ответил gbjbaanb 14 PM00000070000003331 2014, 19:07:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132