New versions should be consistent with Semantic Versioning.

I can't find in the semantic versioning spec where it specifies that all version increments shall be 1 unit steps, to my understanding it only requires incremental versions, thus skipping versions is allow.

This policy could be too much strict for the CI/CD pipelines that automatically increment the patch using an auto-incremented counter that are hard to reset in case of build failure, p.e. when using a counter in azure devops.

It looks like the requirement to increment version numbers by 1 was dropped between semver 1.0.0 and 2.0.0. There's some discussion on their issue tracker. So enforcing increment-by-1 is too strict. I'll close this issue.

This policy could be too much strict for the CI/CD pipelines that automatically increment the patch using an auto-incremented counter that are hard to reset in case of build failure, p.e. when using a counter in azure devops.

Using a build counter as a patch version number should work, but I think it's going to be inconvenient in a lot of cases. If there's a compatible change to the API or to visible functionality, you should increment the minor version number and set the patch version number to zero; a counter can't do that. If there are builds on different branches sharing the same counter, it won't grow together with version numbers either.

Just for completeness, the comment gorelease.go#L109-L112 should be deleted so no one tries to implement this idea without knowing about this discussion.

If there's a compatible change to the API or to visible functionality, you should increment the minor version number and set the patch version number to zero; a counter can't do that. If there are builds on different branches sharing the same counter, it won't grow together with version numbers either.

@jayconrod thanks for the advice, I do take care of this cases.