Expose the resolved git tag name via the CLI (monorepo tagTemplate is unreachable)

[AaronLayton]

Summary

There's no way to ask versionize what git tag it just created. For a single-project repo you
can assume v{version} and be right. As soon as tagTemplate is in play — which is the norm
for monorepos — any downstream tooling has to reimplement versionize's tag resolution, and
that means parsing .versionize and duplicating the template logic.

Why this matters

We drive GitLab releases from versionize in CI. The release step needs the tag name, because
the release object attaches to a tag. Today the CI template hardcodes v${VERSION}, which is
correct for single-package repos and silently wrong for every monorepo package:

what versionize created:   PkgB/v1.0.1
what CI can construct:     v1.0.1

The release then hangs off a tag that doesn't exist, and two packages that happen to share a
version number also collide on the release name.

What I tried

inspect looked like the natural home for this, and 2.6.0 added tag-version printing to it
(#197) — but it returns the version, not the tag:

$ versionize --proj-name PkgB inspect
1.1.0
$ versionize --proj-name PkgB --tag-only inspect
1.1.0            # hoped for PkgB/v1.1.0

The tag name is only available as prose on stdout during a release run
(tagged release as PkgB/v1.0.1 against commit with sha ...), which isn't something a CI
script should be scraping.

Proposal

Any of these would solve it:

1. versionize inspect --tag (or --tag-name) — print the resolved tag for the current
   version, honouring tagTemplate and --proj-name.
2. Have --tag-only inspect print the full resolved tag rather than the bare version, if
   that's closer to the original intent of feat: add support for printing tag version when tag-only option is used in inspect command #197.
3. A machine-readable release summary — e.g. --output-json <path> on the release run,
   emitting { "version": "1.0.1", "tag": "PkgB/v1.0.1", "commit": "..." }. This would also
   cover the CI case of needing version and tag together without a second invocation.

Happy to open a PR if you'll say which shape you'd prefer.

---

Secondary, possibly worth splitting out

versionize changelog can't describe a pending release. It resolves its range from tags,
so it can only run after the release commit and tag exist — which means the release commit
is always inside the range it reports:

$ versionize changelog --version 1.1.0     # before release
Tag for version '1.1.0' not found

$ versionize changelog --version 1.1.0     # after release
### Features
* add a thing (e069524)
### Bug Fixes
* correct a thing (fb881a7)
### Chores
* **release:** 1.1.0  [skip ci]            <- not in CHANGELOG.md

On a config with includeAllCommits: true and the chore section visible, the output can't be
made to match the CHANGELOG.md entry versionize itself just wrote. A --pending mode, or an
option to exclude the release commit, would let CI publish release notes that match the
changelog exactly.

--skip-commit help text doesn't match behaviour. It reads "Skip commit and git tag
after updating changelog and incrementing the version", but it does create the tag (against
the current HEAD). --skip-tag covers the tag separately, so the behaviour looks right and
the help text looks stale — but it's worth confirming which is intended, since it's easy to
build on by accident.

[cabauman]

Thanks for the detailed reports. I'll address the secondary part first.

changelog command

Yeah, I've been wanting to exclude release commits from changelog generation because it doesn't make sense to include those. So thanks for bringing that up.

skip-commit help text

Good catch (it's outdated). It used to skip both, which wasn't intuitive, so we split it into separate options.

[cabauman]

Regarding the git tag topic, sure, I think I prefer option 1. I like option 3 as potential feature addition at a later time.

I think a tag getter feature was left out because we figured it was simple enough to use normal git commands to grab the most recently created tag, like we do in our github-release workflow e.g.

git describe --tags --abbrev=0

But if having a versionize command will improve convenience for monorepos then I'm all for it.