Похоже, что вы обходите обычные соглашения, просто чтобы избежать накладных расходов процесса / аудита. Это ... поразительно для меня.
То, что вы делаете, - это фактически намеренно создаете дополнительный номер версии (ваш младший номер PCI) для того, чтобы переместить вашу функцию / вспомогательные номера версий обратно на место, чтобы больше не запускать критерии внутреннего аудита.
В любом случае, переходя к вашему вопросу о семантическом версионировании, спецификация для семантического версионирования гласит:
Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:
- ОСНОВНАЯ версия, когда вы делаете несовместимые изменения API,
- Версия MINOR, когда вы добавляете функциональность обратно совместимым способом, и
- Версия 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 + СТРОЙ. В основном нам разрешено менять только 3-й и 4-й компоненты без вовлечения PCI (и впоследствии PCI-оверлордов в компании). Мне кажется, что это немного надумано, я не уверен, что они оправданы в том, как они управляют номером версии, но я не знаю достаточно о PCI и процессе аудита, чтобы сказать иначе.
Хорошо это нормально У вас есть система, которая работает для вас и отвечает вашим потребностям. В этом смысл версий.
Если ваш API является закрытым (только внутренним), то на самом деле не имеет значения, как вы работаете с версией, если это имеет смысл для вас и всех, кто его использует. Версионность в стандартном формате имеет значение, когда у вас есть много других потребителей вашего API, которые должны знать, "что означает эта версия?"
Наличие произвольной системы управления версиями приведет в замешательство людей, которые привыкли к другим системам, таким как семантическое управление версиями. Но если никто не использует вашу систему управления версиями, кроме людей, которые ее создают - это не имеет значения.