Чи дозволяє семантична версія дозволити 4 компоненти у номерах версій?

Усі приклади семантичної версії, яку я бачив, показують 3 компоненти, що використовуються. Не більше 2 символів періоду. У $DAYJOBнаших номерах релізу ми використовуємо 4 компоненти:

5.0.1.2

Чи допускає це семантична версія?

І як питання вищого рівня та більш спірне питання, чи це насправді навіть важливо? Я почав думати, що може бути гарною ідеєю застосувати семантичну версію, але в кінцевому підсумку такі об'єкти, як PCI, це перекривають.

Я повинен був уточнити свій коментар PCI. Проблема полягає в тому, що аудиторські перевірки та їх вартість впливають на зміну основних та другорядних компонентів, не обов'язково нову особливість. Наприклад, якщо введено функцію, пов’язану з платежами, ми накопичуємо незначне число для PCI. Але якщо ми додамо абсолютно нову функцію, пов’язану з чимось у gui, це не стане. Змінюється лише патч. Тож у цьому випадку ми дійсно не говоримо з цього питання як розробники, оскільки хтось інший приймає ці рішення.

Здається, що ви обминаєте звичайні умови лише для того, щоб уникнути накладних витрат / аудитів. Це ... вражає мене як щодо.

Що ви робите, це ефективно робити додатковий номер версії (ваш незначний показник PCI) дещо навмисно, щоб перенести свою функцію / незначні номери версій назад на місце, щоб більше не викликати ваші критерії внутрішнього аудиту.

У будь-якому випадку, діючи до вашого питання про семантичну версію, специфікація для семантичної версії говорить:

Враховуючи номер версії MAJOR.MINOR.PATCH, збільшуйте:

• ОСНОВНА версія, коли ви вносите несумісні зміни API,
• МІНОРОЖНА версія, коли ви додаєте функціональність у сумісному сумісному режимі, і
• Версія PATCH, коли ви робите назад сумісні виправлення помилок.
• Додаткові мітки для попереднього випуску та збирання метаданих доступні як розширення до формату MAJOR.MINOR.PATCH .

Наголос мій.

Отже, питання полягає в тому, чи використовуєте ви четвертий символ для передвипуску / збирання метаданих? Або це в основному ще одна вказівка ​​на версію, що випускаєте?

Якщо "так", то параметри семантичної версії цього дозволяють. Якщо "ні", то ви технічно не дотримуєтесь смислової версії.

І як питання вищого рівня та більш спірне питання, чи це насправді навіть важливо?

Хочете ви жорстко слідувати цьому чи ні, це рішення, яке ви повинні приймати з вашою командою. Метою семантичної версії є допомога в сумісності API:

Виправлення помилок, що не впливають на приріст API версії патча, додатково сумісні додатки API / зміни, збільшуючи незначну версію, і назад несумісні зміни API збільшують основну версію.

Я називаю цю систему "семантичною версією". За цією схемою номери версій та спосіб їх зміни передають значення основного коду та того, що було змінено з однієї версії на іншу.

Це система, яка допомагає зробити це більш зрозумілим, коли версія впливає на нижчих користувачів API.

Поки ваш API аналогічно зрозумілим, який шлях ви виберете не дуже. Семантична версія просто виявляється простою, наприклад, якщо я використовую 3.4.2 і мені потрібно оновити до 3.4.10, я знаю, що можу це зробити, нічого не порушуючи. Якщо нова версія 3.5.1, я знаю, що вона сумісна назад. І я знаю, що версія 4.0.1 була б суттєвою зміною.

Це все, що означає номери версій.

@enderland Так, в основному. ГОЛОВНА (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD. В основному нам дозволяється лише змінювати 3-й та 4-й компоненти, не втягуючи PCI (а згодом і PCI суперлідер у компанії). Мені здається, що це трохи надумано, я не впевнений, що вони виправдані в тому, як вони керують номером версії, але я не знаю достатньо про PCI та процес аудиту, щоб сказати інше.

Гаразд, це добре. У вас є система, яка працює для вас і відповідає вашим потребам. У цьому сенс версії.

Якщо ваш API приватний (лише внутрішній), це не має значення, як ви оновлюєте версію, якщо це має сенс для вас і всіх, хто її використовує. Якщо версія в стандартному форматі має значення, коли у вас є багато інших споживачів вашого API, які повинні знати, "що означає ця версія?"

Наявність довільної версійної системи може заплутати людей, які звикли до інших систем, таких як семантична версія. Але якщо ніхто не реально використовує вашу систему версій, крім людей, які її створюють - це насправді не має значення.

У поточній версії Semantic Versioning, що становить 2.0.0 , немає. Існує вимога, яка визначає версію як форму XYZ, де X, Y і Z є негативними цілими числами, які не містять провідних 0:

Нормальний номер версії ОБОВ'ЯЗКОВО приймає форму XYZ, де X, Y і Z - це негативні цілі числа, і НЕ ОБ'ЄДНАТЬ містити провідні нулі. X - основна версія, Y - другорядна версія, а Z - версія патча. Кожен елемент ОБОВ'ЯЗКОВО чисельно збільшується. Наприклад: 1.9.0 -> 1.10.0 -> 1.11.0.

Однак можливість додавання метаданих дозволена для:

Метадані збірки МОЖУТЬ позначатись додаванням знака плюс та серії ідентифікаторів, розділених крапками, безпосередньо після виправлення або версії перед випуском. Ідентифікатори ОБОВ'ЯЗКОВО містять буквено-цифрові символи та дефіси ASCII [0-9A-Za-z-]. Ідентифікатори НЕ ПОВИННІ бути порожніми. Метадані збірки БУДЕ ігноруватися при визначенні пріоритетності версії. Таким чином, дві версії, які відрізняються лише метаданими збірки, мають однаковий пріоритет. Приклади: 1.0.0-альфа + 001, 1.0.0 + 20130313144700, 1.0.0-бета + exp.sha.5114f85.

Щось важливе, що слід зазначити, це те, що Semantic Versioning спеціально для програмного забезпечення, яке декларує загальнодоступний API:

Програмне забезпечення, що використовує семантичну версію, ОБОВ'ЯЗКОВО оголосити публічний API. Цей API може бути оголошений у самому коді або суворо існувати в документації. Однак це робиться, воно повинно бути точним і всебічним.

Це, як правило, підтримує розвиток бібліотек або служб, а не на рівні додатків.

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