Семантическое управление версиями (Semver) - как создавать большие функциональные обновления с обратной совместимостью - PullRequest
Новая
       11

Семантическое управление версиями (Semver) - как создавать большие функциональные обновления с обратной совместимостью

3 голосов
/ 12 апреля 2019

Насколько я понимаю, используя X.Y.Z, мы изменяем только X для прерывания изменений. Y для обратно совместимых функциональных изменений.

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

TLDR Независимо от того, насколько «значительным» является обновление, если оно не является критическим, вы не меняете X для X.Y.Z

1 Ответ

2 голосов
/ 09 июня 2019

Вы можете увеличить основной номер версии для большого функционального обновления с обратной совместимостью. Я утверждаю, что вы обычно должны.

Пункт 8 из Semver 2.0.0 гласит:

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

При строгом применении терминов RFC 2119 МОЖЕТ, ДОЛЖЕН и НЕ ДОЛЖЕН, как указано в справке в Semver, подчеркнутое утверждение означает, что допускается, но не требуется, увеличение основного номера версии, когда изменение включает только незначительные изменения и изменения уровня патча.

Вот что такое огромное количество неразрывных изменений: огромное количество мелких изменений и изменений уровня патча.

В данном параграфе спецификации явно отсутствуют какие-либо утверждения, эквивалентные:

  • Он не должен включать только незначительные изменения и изменения уровня патча
  • В него должны быть внесены обратно несовместимые изменения

На основании параграфа 7 другой допустимой альтернативой будет увеличение младшей версии только в вашем сценарии.

Это хорошо. Он допускает некоторую свободу действий в ситуации, которую вы описываете, когда публичный API технически не изменился назад несовместимым способом, но изменения настолько существенны, что он будет восприниматься как значительное и навязчивое изменение (предположительно) человек) пользователи и / или разработчики.

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

...