SemVer (Семантическое версионирование) как правильно выбрать когда увеличивать minor, а когда patch?

Question

[Дмитрий Щербаков]

Итак, на офф ресурсе кратко написано https://semver.org/lang/ru/

Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:

МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
МИНОРНУЮ версию, когда вы добавляете новый функционал, не нарушая обратной совместимости.
ПАТЧ-версию, когда вы делаете обратно совместимые исправления.
Дополнительные обозначения для предрелизных и билд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату.

С мажором всё понятно, тут вопросов нет. С минором в принципе тоже, особенно когда мы добавляем целые разделы (в приложении) или новые точки входа (в api)

А вот что делать когда в приложении (да я знаю что semver разрабатывался для api, там везде только и видишь api api, а мне нравится semver я хочу везде ее использовать), в одной таблице добавились новые столбцы - это патч или минор? (вроде как патч, ведь толком ничего не поменялось, но вроде как новый функционал)

В подробном описании написано что патч это только исправление багов (а если "забыли" добавить этот столбец таблицы, это считается за баг?)

Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.

Или вот еще пример:
Изменён код определения mime-типа загружаемого файла, была одна функция, а теперь загружена сторонняя библиотека и проверка делается с помощью нее, по сути в коде поменялась одна строчка. Это уже минор и считается новой фичей или это рефакторинг и считается патчем? Ведь теоретически со старой функцией могли быть в будущем проблемы, а с новой этих проблем не будет

А в подробном описании минора указано

Она МОЖЕТ включать в себя изменения, характерные для патчей.

Может просто забить на патчи и пользоваться только мажор.минор и вопросов не возникнет ))

Answer 1

[ApeCoder]

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

Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.

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

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

Comments

[Дмитрий Щербаков]

ApeCoder А можете без привязки к API (представим себе что это не публичное API, а просто приложение) и без цитирования документации на моих примерах сказать минор это или патч?

[ApeCoder]

Дмитрий Щербаков, семантическое версионирование предназначено для решения проблем совместимости API. Если у вас нету API, то вы не можете семантически версионировать. Например как вы определите совместимые и несовместимые изменения?

[Дмитрий Щербаков]

ApeCoder, ааа вон оно где собака зарылась )) теперь всё сразу встало на свои места )) а то я пытаюсь тут применить SemVer там где ему вовсе не место ))

Answer 2

[Arman]

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

Comments

[Дмитрий Щербаков]

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

минорные приносят что-то новое, патч исправляют баги

Это и в доках написано, а новый столбец в таблице это минор или патч?

По теории вроде минор, его ведь не было, а тут появился, с другой стороны если он там должен был быть то это уже баг ))

[Arman]

Дмитрий Щербаков, а зачем новый столбец? потому что без ничего/что-то не работает? - патч. столбец который идет с кодом который добавляет города(?) - минор

[Дмитрий Щербаков]

Arik, ааа, ну да, если допустим с сервера приходят данные city , address , number, а таблица показывает только столбцы city и address ну и выложили в таком виде

все работает багов нет т.к. нечему лагать

а тут раз вспомнили, что number то тоже надо показывать ну и добавили код в шаблон для показа столбцы (данные итак приходят)

по сути что старая версия что новая обе рабочие.

Ну т.е. если бы без этого поля все сломалось тогда добавление поля это патч т.к. чинит баг? А если ничего не чинит значит фича и это уже минор?

[cppjunkie]

Мне кажется в обычных гуйных программах визулальный интерфейс (UI), который видит юзер, можно понимать как API - с точки зрения юзеров это новая фича, поэтому увеличиваем минорную версию (ну как-то так).

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

[Дмитрий Щербаков]

cppjunkie, я внутри кода (в классах, методах) использую дату, раньше с версиями пробовал и забил, с датой проще

Да вы правы, слишком усложняю там где это не нужно, но для себя хотелось понять как правильно делать версии по SemVer, теперь понимаю.