Is your feature request related to a problem? Please describe.
Hi! 👋
I'm packaging this project for Arch Linux.
As a distribution we track the current version of an upstream using nvchecker.
The libcoap project has added tags, that add a trailing letter to a previously released tag (e.g. v4.3.5a, v4.3.5b after adding v4.3.5).
By and large, the version information encoded in these tags is unfortunately considered as "older" than tags without this trailing letter (they are considered as alpha and beta releases, similar to v4.3.5-alpha and v4.3.5-beta).
This is not only an issue for nvchecker, but also with alpm-pkgver (see https://alpm.archlinux.page/specifications/alpm-pkgver.7.html#version-comparison) and AFAIK rpm as alpm-pkgver behaves quite similar.
As such, this does not work reliably with automated version tracking.
In addition, it is rather confusing: By looking at the tag, users may assume that v4.3.5a is an alpha version of v4.3.5, or that v4.3.5b is a beta version of v4.3.5.
Describe the solution you would like
Tagging in accordance with semver would fix this (e.g. instead of v4.3.5a, tag as v4.3.6, etc.).
Describe alternatives you have considered
Currently, the only way to deal with this is to add exceptions to the nvchecker configuration file for every version affected by this.
This is very cumbersome, requires continuous manual checking and is therefore also error-prone.
Additional context
Downstream distributions consist of many volunteers, that have to establish a common understanding of how to use a package and how to upgrade it, as well as how its version affects its dependents.
When following a common rule set (such as semver), this becomes much easier (also for direct users of this project).
Is your feature request related to a problem? Please describe.
Hi! 👋
I'm packaging this project for Arch Linux.
As a distribution we track the current version of an upstream using nvchecker.
The libcoap project has added tags, that add a trailing letter to a previously released tag (e.g.
v4.3.5a,v4.3.5bafter addingv4.3.5).By and large, the version information encoded in these tags is unfortunately considered as "older" than tags without this trailing letter (they are considered as alpha and beta releases, similar to
v4.3.5-alphaandv4.3.5-beta).This is not only an issue for nvchecker, but also with alpm-pkgver (see https://alpm.archlinux.page/specifications/alpm-pkgver.7.html#version-comparison) and AFAIK rpm as alpm-pkgver behaves quite similar.
As such, this does not work reliably with automated version tracking.
In addition, it is rather confusing: By looking at the tag, users may assume that v4.3.5a is an alpha version of v4.3.5, or that v4.3.5b is a beta version of v4.3.5.
Describe the solution you would like
Tagging in accordance with semver would fix this (e.g. instead of
v4.3.5a, tag asv4.3.6, etc.).Describe alternatives you have considered
Currently, the only way to deal with this is to add exceptions to the nvchecker configuration file for every version affected by this.
This is very cumbersome, requires continuous manual checking and is therefore also error-prone.
Additional context
Downstream distributions consist of many volunteers, that have to establish a common understanding of how to use a package and how to upgrade it, as well as how its version affects its dependents.
When following a common rule set (such as semver), this becomes much easier (also for direct users of this project).