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.)
Updated by Tony Fuller almost 4 years ago
Hi Greg,
I'm not in any position to say exactly what the state of things are but as an end user, I do appreciate the work that goes into maintaining and packaging up others software and would like to say "Thanks."
Dan is really the authority here, I'll let ping him on the chirp_devel mailing list to make sure he see this issue.
IMO, not that it matters, appending the build date to the "current version" makes sense if it allows users to easily update their packages. I checked the ./chirp/init.py script and the CHIRP_VERSION is 0.3.0dev. that is only a data point.
Also, Chirp currently depends on at least 2 deprecated packages: python2 and gtk2, does that casue any issues with packaging up things?
Tony
Updated by Dan Smith almost 4 years ago
Yeah, I'm not going back to maintaining stable releases. We do a pretty good job of ensuring that we don't break things with our CI system, so there's really nothing more stable than the latest snapshot. So, yes, packagers should just grab the latest daily and package that, updating whenever convenient.
We chose the YYYMMMDD version number format specifically to be monotonically increasing, so I would recommend you just do that. If you want to suffix it onto something as a hedge for the future, then that's fine, but I can't really imagine ever switching back to static version numbers.
I added a news item for "Uh we stopped releasing stable builds a long time ago"... hope that helps with the confusion a bit.
On the package name, I actually call it "chirp_daily" in the Ubuntu PPA because there is already a "chirp" package that I have no control over. So either chirp or chirp-daily for your purposes seems fine.
Updated by Greg Troxel over 3 years ago
Thanks. I will just treat YYYYMMDD as a true version number, and the package will be "chirp", because that seems like what you would want if you weren't working around the Ubuntu packaging.
I saw the news entry, thanks, so this bug can be closed.