feat(version): Add new version print flags to display the last released version and tag.

[cfxegbert]

This adds a the command semantic-release current-version so semantic-release can be used to determine the current tag on the branch based on semantic-release config.

[codejedi365]

I'd rather see this be a modification to the version command. Is it possible to extend the current --print option funrtion, where your command would be

semantic-release version --print-last-released

[codejedi365]

And also doesn't the --print option do this if you just capture the stdout? It will provide a stderr message but that doesn't stop the return of the current version as long as it hasn't changed?

Or the rationale for this, is to not consider what has changed but only what is currently released?

[cfxegbert]

Or the rationale for this, is to not consider what has changed but only what is currently released?

That is the rationale for this. I have a need to run my CI/CD pipeline periodically for security checks and I want the current version.

[cfxegbert]

Do you think I should be making two versions, one that returns the tag and another returning the semantic version? I could see both being useful.

If I did make a version that printed the tag I would also add a --print-tag to be complete.

[codejedi365]

Thanks for the contribution. Just a few recommendations but I'm glad you were thorough with tests and doc updates.

One minor recommendation. I would rewrite your branch commits to remove at least the first one and then separate out the addition of the click-option-group as its own build(deps): add click-option-group ... because the maintainer tends to rebase and merge with the exact commits used. Once this occurs then a changelog is generated from those commits. If your first commit is in there then that is confusing to what actual features were added and the build change is then hidden from the changelog as its lumped into the feature creation.

[codejedi365]

Very neat!

[codejedi365]

Do you think I should be making two versions, one that returns the tag and another returning the semantic version? I could see both being useful.

If I did make a version that printed the tag I would also add a --print-tag to be complete.

I think having all 4 variants was a great choice, thanks for thinking ahead.

[cfxegbert]

Addressed changes and cleaned up commit log

[codejedi365]

@cfxegbert, good job thanks!

This is an optional change as it doesn't change much for your overall PR, but I wanted to recommend that the pre-commit commit should be of type chore instead. As this software is all about version detection, the fix(pre-commit) commit by itself would actually trigger a patch release of the codebase but chore would not. You would want to reserve feat and fix for specific commits that are related to the source code that is published/consumed by end users. A development environment change does not affect end user so you would not want to cause a patch release itself. This is less relevant for this specific PR as you have an independent feature commit as well so that overrides the fix level commit previously made.

All in all thanks for the effort you have put into this PR!

@relekang, PR ready for merge.

[cfxegbert]

Fix commit messages not to start with a capitol letter and not end with a period

[codejedi365]

Great work! Approved.

Ready for merge @relekang