Repository navigation
Releasing with a VERSION file has a footgun #155
Description
Activity
Hi.
Should what I described be standard behavior?
version_file documentation says:
Please take into account that any tags in the repo are ignored if this option is being used.Maybe optional behavior behind a flag?
It can be an option
prefer_tag: bool, for this use case.I feel there needs to be a strict check that the tag and version are equal
This can break current repos. IMHO there should be a warning if tag and version file content are not the same.
One more question - why
version_fileschema is used in the first place, if you rely on git tag for versioning?One more question - why
version_fileschema is used in the first place, if you rely on git tag for versioning?Shallow clones in CI for non-releases and no guessing about what the next release version is (which is what we particularly disliked about setuptools-scm).
If you have a
version_filesetup and push a tag, the release template that pull in the version info from the file will be used regardless of the value of that tag. We just encountered an issue where we were trying to release an rc prerelease package, so we pushed a tagv2.1.0rc1and this created the package2.1.0by looking directly at the VERSION file. This is definitely on us since we had an LLM cook up the scripts and didn't see through it's faulty assumptions.I think what we want is the tag be compared against the called out version in the
version_file; see that it is compatible since it's a pre, final, or post release; and then use the tag's value over the VERSION file. But in cases where there is no tag, it uses the VERSION file with the derived dev count in the dev template. I would expect we would have to fill intag_formatter(since tags are currentlyv{version}) or switch to using the actual PEP compliant version number as the tag.That all can be accomplished right now with a custom version callback. My questions are.