The result of some case of version compare is not expected

[linxingyun]

Here are some cases of version compare.

Expected result:

version.parse('v6.4.4-build4832') > version.parse('v6.5')
False
version.parse('v6.4.4-build4832') > version.parse('v6.4.4-build')
True

Note expected result:

version.parse('v6.4.4-build4832') > version.parse('v6.4')
False
version.parse('v6.4.4-build4832') > version.parse('v6.4.4-')
False

Note: This may not be expected, since 'v6.4.4' should be greater than 'v6.4'. But it return back 'False' result.
Please help to confirm this issue. Thank you so much.

[brettcannon]

This is expected as e.g. v6.4.9 is also a version of v6.4. So when you drop an entire portion of the version then it is expected to always be greater since it will always be somehow compatible with any v6.4.* version.

I also couldn't find a section in PEP 440 (which you get redirected to from https://packaging.python.org/specifications/version-specifiers/) which suggests that dropping the last digit means it should be considered smaller than a version with it specified. If you can point that out that would be really helpful.

[uranusjr]

I believe PEP 440 is irrelevant here since v6.4.4-build4832 is not a valid PEP 440 version in the first place. This is exactly why we should get rid of LegacyVersion.

[pradyunsg]

See #386 for context on what's happening with LegacyVersion. It's now deprecated per #321 and, we aren't going to be making changes to LegacyVersion anyway.

The suggestion here is to use packaging.versions.Version, and to use PEP 440-based versions.

[MrMino]

Also, build4832 looks like a build number to me, shouldn't it be added within the build tag of the wheel?

[linxingyun]

Thank you guys.

The version build format is not controlled by myself. So it seems to be issue of 'build' text in the version text.

version.parse('v6.4.4-4832') > version.parse('v6.4')
True
version.parse('v6.4.4-b4832') > version.parse('v6.4')
True
version.parse('v6.4.4-build4832') > version.parse('v6.4')
False