Bumpver doesn't recognise tagged versions as lower

[MitchellAcoustics]

Please do correct me if I'm wrong, but my impression is tags, particularly prerelease tags like dev, a, b, rc, etc. should be considered lower than the base version, i.e.: 0.1.0 > 0.1.0-rc1. However, when trying to move from a prerelease to final version, bumpver throws an error:

╰─ bumpver test 'v0.7.5-rc1' 'vMAJOR.MINOR.PATCH[-PYTAGNUM]' --tag=final
ERROR   - Invariant violated: New version must be greater than old version 
ERROR   -   Failed Invariant: 'v0.7.5' > 'v0.7.5-rc1'
ERROR   - If the invariant is from vcs tags try '--ignore-vcs-tag' option.

Is this the expected behaviour?

[mbarkhau]

I think this is expected yes. We have no logic of our own to determine old/new, we just use looseversion.LooseVersion or pkg_resources.parse_version for older versions of python.

See:

• https://pypi.org/project/looseversion/
• https://peps.python.org/pep-0440/#examples

[tzing]

Hi @mbarkhau

I have a follow-up question-

Both PEP-440 and the up-to-date version-specifiers addressed:

Within a numeric release (1.0, 2.7.3), the following suffixes are permitted and MUST be ordered as shown:

.devN, aN, bN, rcN, <no suffix>, .postN

-- Section "Summary of permitted suffixes and relative ordering"

So I think 0.7.5 should be a valid version number and is greater than 0.7.5rc1. Although the OP's example values (v0.7.5 vs v0.7.5-rc1) are a bit different from the spec, does it mean that bumpver does not respect that rule, or I just misconfigured?

[mbarkhau]

My guess is, if the "v" prefix is removed, and perhaps also the "-", then it might work.

[MitchellAcoustics]

I still think there's a bit of an issue, but to update, I think in this case part of it was problems with my git tags. Since I was just getting it set up and experimenting, there were quite a few nonsensical things (out of order tags, lots of dev, rc, etc. tags) which could have confused bumpver and now with things cleaned up it's mostly working the way I would expect.

But what I'd request is an option to override the old/new invariant, particularly when setting explicitly with --set-version. It's definitely a good idea to have the invariant warning by default, but in certain cases it would be helpful just to force bumpver to set it to the version I need and set the tag, whether or not it's in the right order (excluding when the tag already exists, that should still fail). --ignore-vsc-tag didn't seem to do the trick.

[mbarkhau]

If you used --ignore-vsc-tag I'm pretty sure, it simply took the version from your config file. It still does the check for the invariant in that case. I guess you're looking for something like --disable-validation on the bumpver update command?

[MitchellAcoustics]

Yeah, something like that would be useful (with appopriate caveats, maybe even asking for confirmation before proceeding). Since one of the uses of a tool like bumpver is just updating the version string across multiple files, even without reference to vcs, it'd be useful in certain cases to be able to do that to set it to whatever I want.

For a legit example of this, say I have forked another project that is no longer maintained/is archived to make my own version of it. I'd want to reset the version number to v0.1.0, not caring about the fact that it's moving backwards. If they set it up with bumpver pointing to the relevant files, I should be able to just do bumpver update --set-version v0.1.0 --disable-validation.

[mbarkhau]

Ok, it appears you've stumbled upon a genuine issue related to the looseversion.LooseVersion library. I was under the impression that this was a drop in replacement for pkg_resources.parse_version.

Related: #156

[mbarkhau]

This breakage starts with setuptools>=66.0.0. A temporary fix is to pin setuptools<66.0.0;

pypa/setuptools#2497

[mbarkhau]

Have a look at bumpver==2024.1130, I think it should be fixed now.