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.0feat: updates minor +1, and we would get 1.1.0fix: updated patch +1, and gives us 1.0.1I have a couple of questions regarding such a versioning method:
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 ?
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 ?
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.