Page MenuHome GnuPG

gpgconf --query-swdb incorrectly handles pre-release version numbers
Closed, WontfixPublic

Description

This is relevant for the update check in Gpg4win.

Example:

$ gpgconf --query-swdb gpg4win 3.1.16-beta16
gpg4win:3.1.16-beta16:n::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

-> Although 3.1.16 is available gpgconf --query-swdb claims n, i.e. "The installed version [3.1.16-beta16] is already newer than the released version [3.1.16]." Obviously, that's incorrect.

For comparison, the following works correctly:

$ gpgconf --query-swdb gpg4win 3.1.17
gpg4win:3.1.17:n::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

-> Yes, 3.1.17 is newer than 3.1.16.

$ gpgconf --query-swdb gpg4win 3.1.16
gpg4win:3.1.16:c::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

-> Yes, 3.1.16 is the current version.

$ gpgconf --query-swdb gpg4win 3.1.15-beta16
gpg4win:3.1.15-beta16:u::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

-> Yes, 3.1.15-beta16 is older than 3.1.16.

Event Timeline

Thanks for creating the issue.

Note that I am not sure if GnuPG is fully committed on https://semver.org/ already, traditionally GnuPG had its own version numbering scheme. Unless GnuPG is officially doing semver the behaviour is undefined, which is okay.

However I think any new code should at least be robust if semver 2.0 is to be used at some time in the future. And it is good to have at least a defined method for pre-release version numbers, if the need every arises.

The thing is that any n.m.k-something version should behave versionwise the same as n.m.k. That is okay, because beta versions etc are not considered to be released. This is required to allow testing beta version _before_ doing the release.

werner claimed this task.