[SOLVED] Semver minor and patch digit update logic

Semver minor and patch digit update logic

I'm writing a script that bumps up the package version based on the difference in commits between the master and current branch. I'm using conventional commits to decide which number to update.

Let's say, I have 1.0.0 by default

BREAKING CHANGE: updates major +1, and leaves other digits untouched even if there were some other changes, so I get 2.0.0
feat: updates minor +1, and we would get 1.1.0
fix: updated patch +1, and gives us 1.0.1

I have a couple of questions regarding such a versioning method:

If I have several commits on the current branch with the feat: or fix: should I upgrade the minor/patch version according to the number of these commits or should it be only +1 ?

e.g. There are 3 commits with feat: on the current branch, when I merge branch to master should the version be 1.4.0 or just 1.1.0 ?

Should I count fix: if I had feat: already?

e.g. There is 1 feat: and 1 fix:, when merging to master should the version become 1.1.1 or 1.1.0 ?

Solution

Semver does a reset in two cases:

With the more important change. Ex: 1.4.3 -> 1.5.0 -> 2.0.0.
And when released, it takes the most important one. Ex: master is at 1.0.0. You have 5 breaking changes, multiple minors and patches on the current branch. It takes only 1 breaking change into consideration and makes 1.0.0 -> 2.0.0.

Well it's logically the best way as the user of the app doesn't care about the process you have been through in the development.