Should {{tag_name}} replacement still work with --no-tag?

[DJDuque]

I expected the following to work (maybe I misunderstood how people should use cargo-release when they can't push commits to main):

# Step 1: Make a new branch
git switch -c $NEW_BRANCH

# Step 2: Check all commits since the last release
cargo release changes

# Step 3: Update the `CHANGELOG.md` to include anything relevant that was missed
# Then commit the changes e.g.
git commit -am "docs: Update CHANGELOG.md"

# Step 4: Determine what the next version is (according to semver) and give
# `cargo-release` the pleasure of doing all the boring stuff
cargo release --execute --no-publish --no-tag --allow-branch=$NEW_BRANCH $NEW_VERSION

# Step 5: Open a pull request and review/merge to `main`

# Step 6: Release from the main branch
git checkout main
git pull
cargo release --execute

Everything works as I expect, except the {{tag_name}} replacement in my changelog. Would it make sense for this to work? Or am I missing something?

[DJDuque]

For anyone using this same workflow, you can work around it by changing the {{tag_name}} replacement for v{{version}}.

Note that the last cargo release --execute will apply your pre-release-replacements again (see #810). You will also need to change this for (I think):

cargo  publish
cargo release tag --execute

[epage]

I don't have strong feelings on this. I think the assumption for how it is is that tag is disabled in config so there is never a tag_name but it can also be disabled on the CLI. Technically, there isn't a tag_name in these scenarios but there also isn't a version either (no version bump). Seems plausible that people can plan for expected tags like they plan for expected versions.