TimothyJones
commented
1 year ago Ah, I had the exact same question when I started using automated semantic versioning tools.
The semver spec says:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
The key point here is that incrementing the minor version number is not about counting the number of features, it's about saying "this release includes some new feature(s), but not breaking changes".
Tools likecommit-and-tag-version, standard-release and release-please create semver release numbers from all the commits since the last release by looking for the most significant change, and incrementing the part of the version that corresponds to that change. So, if you're wanting to generate release numbers, you're using it right and getting the expected output.
If you need version numbers for the commits in-between your releases, you might be interested in absolute-version, which I built for the use-case of reasoning about unreleased versions (useful for contract testing tools, reporting on staging environments, and a few other situations). It doesn't commit or make any tags, but it will give you a human-readable version that describes the state since the last release.
Feel free to close this if this answers your question.
I do automated versioning through Jenkins in my build.
We usually always accumulate many commits, for example:
What criteria was used to generate a 3.71.0 version. Since we have 4 feat commits, it should generate version 3.74.0, right? Why doesn't it work like that?