Bug #8067
closedVersion guidance for packagers is unclear
0%
Description
I maintain several ham packages in pkgsrc, and have a question about chirp versioning policy. I see in "News" that the latest release is 0.4.1. (It would help new people to have a News entry that there are no more releases numbered like that and that daily builds are either in lieu of releases or actually are releases.)
While pkgsrc generally has a notion of packaging only releases, and not snapshots, it seems really clear that we should package some recent daily build, and not have a package for 0.4.1.
The current tarballs that are perhaps releases are labeled YYYYMMDD. It is not clear to me if the project considers them to be "releases" or "snapshots" and how we should assign version numbers for the pkgsrc package. It is also not clear if the use of YYYYMMDD is a permanent commitment, or if the door is open to a 1.0 some day.
Packaging systems very much want to have increasing version numbers, so I wonder which of these is better:
use 20200711 as the version, deciding that it is a release (with an 8-digit version number). Assume that the project commits to there never being a 1.0 which would sort as less than these.
use 0.4.1.20200711 as the version, so that if 1.0 (or even 0.5) is released, the snapshots will sort less than the version.
Also, despite the source being "chirp-daily-20200711", I am assuming the package should be "chirp".
(This ia a bug report because the web site doesn't explain how releases/builds work. I am assuming that the plan is well understood and just not noted, a very minor and easy to fix issue.)