When enable consolidate-commits, commit message's placeholder not been replaced

[jolestar]

release.toml

disable-push = true
disable-publish = true
disable-tag = true
consolidate-commits = true
pre-release-commit-message = "Release {{version}}"
post-release-commit-message = "Released {{version}}, starting {{next_version}}"

I try to add pre-release-commit-message template config or use the default message template.

commit message:

Author: jolestar <jolestar@gmail.com>
Date:   Tue Jul 21 15:41:24 2020 +0800

    Released {{version}}, starting {{next_version}}

commit e7ce20ec0473f75f4275dbd99582494b6f4f2369
Author: jolestar <jolestar@gmail.com>
Date:   Tue Jul 21 15:40:36 2020 +0800

    Release {{version}}

[epage]

Hmm, doesn't look like it is documented but atm the only variable we support for consolidated commits is "date".

The problem is knowing which crate's version, name, next_version, etc should be used for the consolidated commit. Each crate could be different. Any crate could be excluded.

I have been interesting in adding support for bumping the version to an absolute version rather than a relative version. That would make it consistent across all crates and could then be included.

[kpcyrd]

I ran into this issue after setting everything up, is there a workaround I could use? Maybe consolidate-commit-msg? Every crate in my workspace has the same version and I'm releasing with eg. cargo release 0.6.0.

I'm considering manually hardcoding the next version in release.toml before releasing.

[pguedes]

i have the same as @kpcyrd ... i publish all my crates as one consolidated version so ideally there would be options that would allow to consolidate commit message and tags - tags kinda works but we get tags per crate which creates a lot of tags but also is cool if you want to view changes per crate.

I guess perhaps a flag to treat releases at workspace level that would fail (proper error msg) if user tried this on workspace with member that had different versions?

currently i do --skip-push and them git commit --amend to manually fix version, but i also have a test branch that circleci auto-releases beta from which is now publishing broken version messages :(

[pguedes]

had a look at your code and this seems to work for me (only version) #246

adds version into commit message template only if all crates have the same version

[epage]

Been giving this thought and want to solicit input on options and their trade offs to see what would work for people

A solution can involve more than one of these and could even have some "quick wins" now and be expanded in the future

When sharing your preference, please also share your use case so we understand why your crates can have a shared version and if there are any particularities with your workflow for us to understand to help with this.

Options

Include on same-version

This is the route taken with #246

• Its simple
• Relies on the user always doing releases in lock step and will be easy to miss for the times they don't

Include on absolute bump levels

This is for when the user explicitly states the version is the same for all, and not just when it happens by chance.

• Its simple
• Relies on the user always specifying the full version on every release

Config flag to error on version mismatch

When a set of crates are releasing, if they aren't in lock step, error with a remediation. We can suggest the max version as the absolute version to pass in

We only do this per-crate that sets the flag

Config flag to bump to snap to high water mark

When doing a relative version bump, we bump all crates, perform a max on the versions, and treat that as the version for all of them

We only do this per-crate that sets the flag

Use the root crates version

If the root crate isn't released, what do we use?

Recommendation

Start with "Config flag to error on version mismatch". If we name the flag generically, we can later add "Config flag to bump to snap to high water mark"

Flag name ideas

• global_version (Lerna uses that term)
• unified_version
• shared_version
• consolidated_version (just because we have conolidated_commits and consolidated_pushes)

I lean towards shared_version because I propose we allow individual crates to opt-out, like we do with consolidate-commits.

EDIT: Looks like cargo workspace calls it independent.