Срочные изменения в предыдущем основном выпуске - PullRequest
0 голосов
/ 28 сентября 2018

Я ищу руководство для следующего сценария -

Предположим, что у нас есть следующие несколько производственных версий общедоступного API -

1.1.0

2.1.2

Если в исправлении версии "1.1.0" была обнаружена ошибка / дефект, который привел бы к нарушению несовместимого изменения, как нужно было бы обрабатывать управление версиями?После выхода из строя критическое изменение потребует увеличения основной версии, поэтому «1.1.0» должен стать «2.0.0».Тем не менее, у нас уже есть следующая основная версия «2.1.2», в которой есть свои изменения.

Желательно ли пропустить номера между основными обновлениями версий, чтобы приспособиться к таким сценариям?то есть следующая запланированная основная версия после "1.0.0" должна была быть "3.0.0"?

Любые другие предложения?

1 Ответ

0 голосов
/ 28 сентября 2018

, поэтому "1.1.0" должно стать "2.0.0"

Не верно.Мало того, что у вас уже есть 2.0.0, спецификация semver не требует монотонности.Вы можете выпустить его как 3.0.0 или 100.0.0.Однако, как правило, именно здесь вы прекращаете поддержку серии 1.yz и предлагаете людям перейти на существующие версии 2.yz

. Другой вариант - объединить наборы функций 1.0.0 и 2.0.0.в 3.0.0.

ADDENDUM:

В прошлом вы сделали определенный выбор, который повлияет на будущее развитие вашего фирменного продукта и вашу репутацию организации.Когда вы заявляете, что применяете семантическое управление версиями, вы НЕ ДОЛЖНЫ выпускать последние изменения, не увеличивая номер основной версии.Чем дольше вы придерживаетесь указанной семантики, тем больше ваши клиенты будут доверять вашему требованию.

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

Запретить какие-либо договорные обязательства между вами и вашими клиентами, я бы посоветовал быть максимально прозрачным сих, как вы, возможно, можете.Объясните загадку брендинга и управления версиями и переименуйте ваш продукт 1.yz так, чтобы он мог придерживаться семантического управления версиями.Если у вас был продукт X, переименуйте его в X.Classic или что-то подобное.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...