feat: New version option --auto-height

[ccopsey]

A proposed feature to autocalculate the numeric value of a pre-release label using the shortest distance to the latest version tag. This is enabled using convco version --bump --prerelease label --auto-height.

This facilitates ensuring each commit of a pre-release (which I use for feature branches) gets a meaningful version without needing to tag those commits. Tagging commits on a feature branch, before deleting the branch during merge, would lead to those commits becoming headless.

I'm happy for this to be rejected if it is out of scope for this project

[hdevalke]

Thank you for the pull request and the idea. However, when multiple commits are added, this would create jumps in the pre-release numbering.

Tagging commits on a feature branch, before deleting the branch during merge, would lead to those commits becoming headless.

Why should this be an issue? The release pipeline could delete the pre-release tags once released. If there is no tag, it will be hard to find out which commit is -alpha.5 for example.

You could also work around this if you do not want to create tags by calculating your version:

❯ convco version --bump --prerelease beta
0.5.2-beta.1
❯ next_prerelease="$(convco version --bump)-beta.$(git rev-list --count origin/main..HEAD)"

❯ echo $next_prerelease 
0.5.2-beta.2

As you can see in the example, where there are 2 conventional commits between HEAD and the origin/master, making the beta version start at 2 instead of 1.