Make parts of a new version available for [[before commit]] commands

[gdubicki]

Hi! Thanks for another nice tool, @dmerejkowsky ! :)

I started to use it for GitLabForm but I run into a limitation, at least from my use case point of view.

I am trying to follow PEP 440. When I make pre-releases or post-releases I often don't add new changelog entries for them.

For example when I release v.2.2.0rc2 for a small beta-testers group testing, the changelog mentions only 2.2.0, because 2.2.0.rc2 is just another try to make final 2.2.0 version right.

For post-released like 2.0.6.post4 there is also often no changelog entry as it's not a functionally different release.

Because of that I would like to be able to use major, minor and patch numbers of the new version for the [[before commit]] commands.

For example like this:

grep -q -P "^### {major}\.{minor}\.{patch}$" CHANGELOG.md

Or maybe it is possible and I just don't know how to do it..?

[dmerejkowsky]

Nope. You can only use {current_version} and {new_version} in the hooks commands.

There are several approaches we could take:

1/ Adapt the syntax. I think what you're proposing cannot work because we don't know if {patch} should be the patch number for the old version or the new version ... Maybe something like {current_major} ? But then what if there's a regex group named 'current' in the config file ? Or {current.major} with a dot ?

2/ Keep the configuration syntax the same, but pass a "context" to the hook - for instance a json dict with all the metadata serialized in an environment variable? This looks a bit brittle.

3/ Do nothing. Since the hooks can be arbitrary commands, it's relatively easy to parse the current and new version and figure out what the major and minor numbers are. You may want to parse the tbump.toml file to make sure the groups are correct, but I'm not sure it's even necessary.

By the way, the hook that checks that the version number is in the changelog is just there for the example, it's not terribly useful since it's generally pretty easy to update the changelog after the release has been made .

In real life, we use hooks it to generate files that need to be under version control, change when the version is bumped, but cannot be edited by hand. Typically, for a Rut project, we call cargo build to generate the Cargo.lock file.

[dmerejkowsky]

Some skeleton if you want to see what 3/ would like:

import sys
import re

new_version = sys.argv[1]
regex = re.compile(
   .... # whatever regex is in tbump.toml
    re.VERBOSE,
)
match = regex.match(new_version)
assert match

public_version = "{major}.{minor}.{patch}".format(**match.groupdict())

check_changelog_contains(public_version)