Is there a documentation of the version/tag comparing and version testing mechanism available?

[DiMarco1976]

Hello and a good day,

it's my second question, but maybe it's interesting for all.
Is there a documentation or deeper insight of the version comparing (-gt ) and version testing mechanism (test) available?
Does the version checkup include searching for strings like "pre" or "rc" or "cand" and so on?

I. M2TeamArchived/NSudo (this works)

newest tag =
lastversion https://github.com/M2TeamArchived/NSudo --having-asset --pre --format=tag --> 9.0-Preview1 --> correct

newest version =
lastversion https://github.com/M2TeamArchived/NSudo --having-asset --pre --> 9.0rc1 --> correct parsing

version comparing to the stable 8.2 before =
lastversion 8.2 -gt 9.0rc1 --> 9.0rc1 --> correct

II. git-for-windows/git (this don't work as expected)

Second newest version incl. --pre (manual link)
lastversion https://github.com/git-for-windows/git/releases/download/v2.41.0-rc2.windows.1 --> 2.41.0 --> would expect 2.41.0rc2

Second newest version tag (manual link)
lastversion https://github.com/git-for-windows/git/releases/download/v2.41.0-rc2.windows.1 --format tag --> v2.41.0.windows.1 --> would expect v2.41.0-rc2.windows.1

newest version
lastversion git-for-windows/git --having-asset --pre --> 2.41.0 --> correct

comparing by tags not versions
lastversion v2.41.0.windows.1 -gt v2.41.0-rc2.windows.1
leads to "lastversion: error: argument -gt/--newer-than: v2.41.0-rc2.windows.1 is an invalid version value"

testing this spelling of a release candidate
lastversion test 2.41.0-rc1.windows.1 --> Parsed as: 2.41.0 / Stable: True --> expected v2.41.0rc2 Stable: False

comparing a possible expected solution
lastversion 2.41.0 -gt 2.41.0rc2 --> 2.41.0 --> correct
lastversion 2.41.0rc1 -gt 2.41.0rc2 --> 2.41.0rc2 --> correct (also comparing two pre-versions works as expected)

Newest download is always fully functional, only the version check is impossible because both parses to 2.41.0. The leading "v" doesn't seem to be the problem for parsing.

Is it possible to give an idea of what are the limitations of the version check solution -gt? Is it arranged MAJOR [X??.] MINOR [X??.] PATCH[X??]+RC[X?? ] whereby the "release candidate flag" can also occur within MAJOR, MINOR or PATCH-section?

Besides, I am getting deeper into your tool, all-in-all it is perfect for use!

[dvershinin]

Hi!

Sorry I couldn't reply this any earlier as it skipped my notifications inbox somehow. Either way, when you're passing URL to lastversion it's merely a convenience method of specifying project location and anything after <owner><project name> is discarded from URL and does not influence which version is being checked by lastversion. In other words, whichever URL of a GitHub project you pass to it, it will always look at latest version, not the one you might see or reference with the specific URL.

The version checkup uses some normalization of strings first then converting those to a Version object which has comparison capabilities (in other words it tries to make it as a version string as per https://peps.python.org/pep-0440/ ). So as far as your question if it is MAJOR [X??.] MINOR [X??.] PATCH[X??]+RC[X?? ], the internal format it should convert a tag/string to is [N!]N(.N)*[{a|b|rc}N][.postN][.devN] it doest not currently use all the qualifiers, but you can expect lastversion to universally detect the primary component [N!]N(.N)*[{a|b|rc}N]. In other words, it may not always see the post release version.

If something doesn't work as expected it's simply a bug and should be posted to issue tracker. I fixed some of the problems you're been experiencing, e.g. 2.41.0-rc1.windows.1 will now be properly identified as rc1 (and post release 1). Please try lastversion v3.2.0 and I'm looking forward to further feedback! :)