Разрешает ли Semantic Versioning 4 компонента в номерах версий?

16

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

5.0.1.2

Позволяет ли это семантическое управление версиями?

И как вопрос более высокого уровня и более спорный, действительно ли это имеет значение? Я начал думать, что было бы неплохо реализовать семантическое управление версиями, но в конечном итоге такие объекты, как PCI, переопределяют его.

Я должен был уточнить мой комментарий PCI. Проблема заключается в том, что аудит и их стоимость влияют на изменение основных и второстепенных компонентов, что не обязательно является новой функцией. Например, если введена функция, связанная с платежами, мы добавим дополнительный номер для PCI. Но если мы добавим новую функцию, связанную с чем-то в графическом интерфейсе, это не так. Меняется только патч. Так что в этом случае мы, как разработчики, не имеем права голоса в этом вопросе, поскольку кто-то другой принимает эти решения.

versioning semantic-versioning pci void.pointer
источник
Семантическое управление версиями - это руководство. Где PCI заявляет что-нибудь о том, как вещи должны быть версионированы?
Я должен был уточнить мой комментарий PCI. Проблема заключается в том, что аудит и их стоимость влияют на изменение основных и второстепенных компонентов, что не обязательно является новой функцией. Например, если введена функция, связанная с платежами, мы добавим дополнительный номер для PCI. Но если мы добавим новую функцию, связанную с чем-то в графическом интерфейсе, это не так. Меняется только патч. Так что в этом случае мы, как разработчики, не имеем права голоса в этом вопросе, поскольку кто-то другой принимает эти решения.
void.pointer
@ void.pointer Можете ли вы привести пример того, почему вы используете четвертый компонент? Используете ли вы его для обхода внутренних структур затрат и учета - позволяя вашей команде отслеживать новые функции без увеличения количества исправлений?
enderland
@enderland Да в основном. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD, В основном нам разрешено менять только 3-й и 4-й компоненты без вовлечения PCI (и впоследствии PCI-оверлордов в компании). Мне кажется, что это немного надумано, я не уверен, что они оправданы в том, как они управляют номером версии, но я не знаю достаточно о PCI и процессе аудита, чтобы сказать иначе.
void.pointer
4
Мы также используем 4 группы, а не 3. Почему? Потому что C ++. C ++ имеет двоичную обратную совместимость и исходную обратную совместимость: первое подразумевает второе, но отношение не является симметричным. Таким образом, мы используем четвертую группу для двоичной совместимости (вы можете выполнить оперативное исправление системы) и третью группу для совместимости с исходным кодом (вам нужно перекомпилировать, но вам не нужно изменять свой собственный код). И вы знаете, что это работает для нас!
Матье М.

Ответы:

21

Похоже, что вы обходите обычные соглашения, просто чтобы избежать накладных расходов процесса / аудита. Это ... поразительно для меня.

То, что вы делаете, - это фактически намеренно создаете дополнительный номер версии (ваш младший номер 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, которые должны знать, "что означает эта версия?"

Наличие произвольной системы управления версиями приведет в замешательство людей, которые привыкли к другим системам, таким как семантическое управление версиями. Но если никто не использует вашу систему управления версиями, кроме людей, которые ее создают - это не имеет значения.

enderland
источник
Относительно вашего редактирования вверху: позвольте мне сыграть адвоката дьявола здесь. Аудиты PCI стоят компании денег, и не каждая реализованная функция их беспокоит. Так зачем же брать на себя расходы и другие накладные расходы только на принципах? Как это так касается? Я понимаю, что метод определения аудитов, вероятно, ошибочен, но разделение интересов кажется разумным. Вещи, не имеющие отношения к обработке карт, не имеют отношения к PCI.
void.pointer
@ void.pointer Я не могу судить, почему / как определяется ваш аудит. Но кто-то решил, что хочет провести аудит на основе определенных критериев. Намеренно обход , что критерии аудита кажется относительно (независимо от того, сколько денег вы сэкономите, делая это).
enderland
1
@ void.pointer, enderland прав. Если террорист угрожает убить вашу семью, если ваши версии не состоят полностью из букв алфавита, настоящая проблема - это террорист. Не стесняйтесь не следовать семантическому версионированию, чтобы обойти это (на самом деле, я бы настоятельно рекомендовал это в этом случае), но это действительно так: обходной путь, вызванный другой проблемой.
Пол Дрэйпер
1
@PaulDraper Когда Semver стал Единственно верным путем к версии?
Энди
1
@ Энди, это не так. ОП спросил о SemVer. ИДК почему, но это то, что он сделал.
Пол Дрейпер
8

В текущей версии Semantic Versioning, которая является 2.0.0 , нет. Существует требование, определяющее версию как форму XYZ, где X, Y и Z являются неотрицательными целыми числами, которые не содержат ведущих нулей:

Нормальный номер версии ДОЛЖЕН принимать форму XYZ, где X, Y и Z являются неотрицательными целыми числами и НЕ ДОЛЖНЫ содержать начальные нули. X является основной версией, Y является вспомогательной версией, а Z является версией патча. Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 -> 1.10.0 -> 1.11.0.

Однако возможность добавлять метаданные разрешена для:

Метаданные сборки МОГУТ обозначаться добавлением знака плюс и серии разделенных точками идентификаторов сразу после исправления или предварительной версии. Идентификаторы ДОЛЖНЫ содержать только буквенно-цифровые символы ASCII и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Метаданные сборки ДОЛЖНЫ игнорироваться при определении приоритета версии. Таким образом, две версии, которые отличаются только метаданными сборки, имеют одинаковый приоритет. Примеры: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Однако важно отметить, что семантическое управление версиями специально для программного обеспечения, которое объявляет общедоступный API:

Программное обеспечение, использующее Semantic Versioning, ДОЛЖНО объявить общедоступный API. Этот API может быть объявлен в самом коде или существовать строго в документации. Как бы это ни было сделано, оно должно быть точным и всеобъемлющим.

Это имеет тенденцию поддерживать развитие библиотек или служб, а не на уровне приложений.

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

Томас Оуэнс
источник
+1 для публичной заметки API. У нас нет общедоступного API, но у нас есть возможность нарушить обратную совместимость в других аспектах, таких как данные. Возможно, мы поставляем сборку, которая устанавливается поверх старых выпусков, но данные не меняются, и мы больше не можем читать эти данные (обычно мы поддерживаем старые форматы)
void.pointer