Чому 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-альфа + 001, 1.0.0 + 20130313144700, 1.0.0-бета + exp.sha.5114f85.

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

Відповідь - просто використовувати 4 цифри (як правило, системи Microsoft). Четвертий - номер збірки і використовується "лише для інформації". Зазвичай люди ставлять туди номер версії сховища (якщо вони використовують SVN або TFS або подібне), що дуже добре, оскільки ви можете перевірити, яка саме комісія була використана для створення бінарних файлів. Якщо у вас такого немає, то номер збірки CI є розумним наближенням (як ви сподіваєтесь, що ваша система CI може запам'ятати номери збірок і прив’язати їх до історії репо, але ви не покладаєтесь на CI система запам'ятовування їх - ви ніколи не можете видаляти старі складання).

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