why not 👍

__version_info__ is found in some other packages (https://softwareengineering.stackexchange.com/questions/375922/whats-the-version-info-function-in-a-pypi-package) to do clean comparison, but not used indeed.

Obviously, re.split() can also be used to parse __version_info__ if it's needed. Your call.

I'm ok with removing it.

@thp, the idea was to visually separate the adaptive revisions from the master branch releases, but as seen, this may cause more problems than it solves.

The reasonable options are to use re.split('.|+') for splitting the version string everywhere (see the latest push) or I start to use '.' as the adaptive revision separator. Either way is fine for me, but I would prefer the first option.

Using a +adaptive-N suffix would make it a local version, according to https://www.python.org/dev/peps/pep-0440/#development-release-separators. Is it what we're after?

Interesting link. The latest push now handles the local version label as required in PEP 440 and leaves the public version part handling as it was.

BTW, there's a Python library function for version number parsing called packaging.version.parse (also included in setuptools as pkg_resources.packaging.version.parse), but using that requires adding either packaging or setuptools as dependency.

Adding the extra dependency seems a bit too much.

Regarding versioning, what format do you intend to use: 3.10.21+1 or 3.10.21+adaptive-1?

It seems to work as expected anyway:

>>> convert('3.10.21+1')
(3, 10, 21, 1)
>>> convert('3.10.21')
(3, 10, 21)
>>> (3, 10, 21, 1) >= (3, 10, 21)
True
>>> (3, 10, 21, 1) >= (3, 10, 22)
False
>>> convert('3.10.21+adaptive-1')
(3, 10, 21, 'adaptive-1')
>>> convert('3.10.21+adaptive-1') >= convert('3.10.21')
True
>>> convert('3.10.21+adaptive-1') >= convert('3.10.22')
False

I'll leave the adaptive branch versioning as it is, ('3.10.21+1' etc.), unless there is good reason to change it.

That's it then :-)

Thanks