SemVer (Semantic versioning) how to choose when to increase minor and when to increase patch?

Question

Programming

So, on the off resource it is briefly written https://semver.org/lang/ru/

Given a version number of MAJOR.MINOR.PATCH, increment:
MAJOR version when backward incompatible API changes are made.
A MINOR version, when you add new functionality without breaking backwards compatibility.
PATCH version when you make backward compatible fixes.
Additional designations for pre-release and build metadata are possible as additions to the MAJOR.MINOR.PATCH format.

Everything is clear with the major, there are no questions here. With a minor, in principle, too, especially when we add entire sections (in the application) or new entry points (in the api
) I like semver, I want to use it everywhere), new columns have been added in one table - is it a patch or a minor? (it seems like a patch, because nothing really changed, but it seems like a new functionality)
The detailed description says that the patch is only a bug fix (and if you "forgot" to add this table column, is it considered a bug?)

A patch version of Z (xyZ | x > 0) MUST only be incremented if it contains backward compatible bug fixes. The definition of a bug fix means internal changes that fix incorrect behavior.

Or here's another example:
The code for determining the mime type of the uploaded file has been changed, there was one function, and now a third-party library is loaded and the check is done using it, in fact, one line has changed in the code. Is it already a minor and is considered a new feature, or is it a refactoring and is considered a patch? Indeed, theoretically, there could be problems with the old function in the future, but there will be no such problems with the new one.
And in the detailed description of the minor, it is indicated

It MAY include patch-specific changes.

Maybe just forget about patches and use only major.minor and there will be no questions))

Answer 1

If your changes are part of the API, then you increase the minor version, if these are internal changes that do nothing with the API, then this is a patch.
Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.
Минорная версия (x.Y.z | x > 0) ДОЛЖНА быть увеличена, если в публичном API представлен новый обратно совместимый функционал. Она ДОЛЖНА быть увеличена, если какой-либо функционал публичного API помечен как устаревший (deprecated). Она МОЖЕТ быть увеличена в случае реализации нового функционала или существенного усовершенствования в приватном коде. Она МОЖЕТ включать в себя изменения, характерные для патчей. Патч-версия ДОЛЖНА быть обнулена, когда увеличивается минорная версия.
The major version of X (Xyz | X > 0) MUST be incremented if any backward incompatible changes are introduced in the public API. It MAY include changes specific to the minor version level and patches. When the major version is incremented, the minor and patch versions MUST be reset to zero.

Answer 2

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