Why storing current_version?

[JulienPalard]

Accordin to the README:

To avoid this issue, bumpver treats Git/Mercurial tags as the canonical / SSOT

so, why does bumpver forces me to also add my current_version to pyproject.toml? I don't like the idea of having my version stored in two different places, and it would create unusefull diffs when changing both.

If I remove current_version from pyproject.toml I'm getting:

$ bumpver update --dry --no-fetch
WARNING - Couldn't parse pyproject.toml: Missing 'current_version' configuration
ERROR   - Could not parse configuration. Perhaps try 'bumpver init'.

[mbarkhau]

I could go either way on this.

• On the one hand, the purpose of bumpver is to update multiple version strings in a repo, so what's one more as info together with the configuration of the version string?
• On the other hand I guess it really isn't needed, the only thing is, we would have to cover the initial case where there are no version tags yet in the commit history. Probably in that case we would use the same default version that bumpver init uses.

If you want to work on a PR, I'll accept it.

[paultiplady]

Just wanted to add more context on a usecase for this -- I'm currently considering a "tag only" strategy where I don't make a commit the version bump, and instead we just store the latest version in git.

bumpver seems to be really close to supporting this, I think it would be something like commit = false, tag = true in the config. Tools like bumpversion don't seem to support pulling the latest tag from the git repo, which is a really nice feature.

As you note, it wouldn't be able to update strings in the repo. OTOH, for lightweight releases where a build pipeline kicks off for a tag, sometimes you don't want to have to commit & trigger a new pipeline just for the tag. (In my case, I've already run a fairly robust pipeline on every commit to master, so when cutting a release from a given commit, I just want to promote the image that I already built for that SHA to a numbered release.)

Unfortunately I don't have bandwidth to contribute right now, but I may come back to this and see how much work it would be to add in. Just wanted to checkpoint my thinking & share it here in case it was useful.

[mbarkhau]

Hi @paultiplady, sounds like a plan +1.

[radusuciu]

I'm running into a separate issue that the proposed change may address as well. I develop using docker and use multi-stage builds where I first copy pyproject.toml and an associated lock file, install dependencies based on those, and then copy everything to a final runtime stage alongside my code. If my build dependencies do not change, then everything is cached and the build goes quickly. However, when I use bumpver which increments current_version in pyproject.toml, the hash of the file changes, the cache is invalidated, and as a result all of my deps get resolved and installed again, even if they didn't need to be.

Here's a blog that touches on this: https://pythonspeed.com/articles/poetry-vs-docker-caching/

I suppose the most sensible workaround for this would be to use bumpver.toml to configure bumpver instead of pyproject.toml.

[malnvenshorn]

This is also something that bothers me a bit. Because bumpver fetches the latest version from vcs tags, there is not need to hard code the number in the config file. Even if no tag exists the tool could point to the --set-version parameter to initially set the first version. But there is an easy workaround I'm using for now.

[bumpver]
current_version = "0.0.0"

[bumpver.file_patterns]
"pyproject.toml" = []

The config parser is happy. Additionally current_version is used as a default and will never be updated.