SemVer (Семантическое версионирование) как правильно выбрать когда увеличивать minor, а когда patch? Итак, на офф ресурсе кратко написано https://semver.org/lang/ru/ Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать: МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API. МИНОРНУЮ версию, когда вы добавляете новый функционал, не нарушая обратной совместимости. ПАТЧ-версию, когда вы делаете обратно совместимые исправления. Дополнительные обозначения для предрелизных и билд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату. С мажором всё понятно, тут вопросов нет. С минором в принципе тоже, особенно когда мы добавляем целые разделы (в приложении) или новые точки входа (в api) А вот что делать когда в приложении (да я знаю что semver разрабатывался для api, там везде только и видишь api api, а мне нравится semver я хочу везде ее использовать), в одной таблице добавились новые столбцы - это патч или минор? (вроде как патч, ведь толком ничего не поменялось, но вроде как новый функционал) В подробном описании написано что патч это только исправление багов (а если "забыли" добавить этот столбец таблицы, это считается за баг?)Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение. Или вот еще пример: Изменён код определения mime-типа загружаемого файла, была одна функция, а теперь загружена сторонняя библиотека и проверка делается с помощью нее, по сути в коде поменялась одна строчка. Это уже минор и считается новой фичей или это рефакторинг и считается патчем? Ведь теоретически со старой функцией могли быть в будущем проблемы, а с новой этих проблем не будет А в подробном описании минора указаноОна МОЖЕТ включать в себя изменения, характерные для патчей. Может просто забить на патчи и пользоваться только мажор.минор и вопросов не возникнет ))
Прежде всего, важно помнить, что правила SemVer не являются жесткими и абсолютными, и в конечном итоге решение о том, когда увеличивать версию, остаётся на усмотрение разработчика и может зависеть от специфики проекта.
В вашем конкретном случае, если добавление новых столбцов в таблицу не нарушает обратную совместимость и не вносит существенных изменений в функционал, то это скорее всего можно отнести к патч-версии. По сути, это расширение текущего функционала, а не полностью новый функционал.
Относительно изменения кода для определения mime-типа файла, здесь важно осознать, что внесённое изменение имеет значение для пользователей или влияет на их поведение. Если это изменение направлено на решение проблем или улучшение текущего функционала, то скорее всего это можно считать патчем. Однако, если это изменение привносит существенное нововведение и может рассматриваться как новая функциональность, то вероятно стоит рассмотреть увеличение минорной версии.
В конечном итоге, важно принимать решение на основе осознания влияния внесённых изменений на пользователей и соблюдения общепринятых правил семантического версионирования при необходимости.
Прежде всего, важно помнить, что правила SemVer не являются жесткими и абсолютными, и в конечном итоге решение о том, когда увеличивать версию, остаётся на усмотрение разработчика и может зависеть от специфики проекта.
В вашем конкретном случае, если добавление новых столбцов в таблицу не нарушает обратную совместимость и не вносит существенных изменений в функционал, то это скорее всего можно отнести к патч-версии. По сути, это расширение текущего функционала, а не полностью новый функционал.
Относительно изменения кода для определения mime-типа файла, здесь важно осознать, что внесённое изменение имеет значение для пользователей или влияет на их поведение. Если это изменение направлено на решение проблем или улучшение текущего функционала, то скорее всего это можно считать патчем. Однако, если это изменение привносит существенное нововведение и может рассматриваться как новая функциональность, то вероятно стоит рассмотреть увеличение минорной версии.
В конечном итоге, важно принимать решение на основе осознания влияния внесённых изменений на пользователей и соблюдения общепринятых правил семантического версионирования при необходимости.