On Thu Nov 28, 2024 at 10:44 AM CET, Simon Josefsson wrote: > Otto Kekäläinen <o...@debian.org> writes: > > >> The commit hash. 007c9af. > > > > I disagree here - to me the git commit hash is the single most > > important identifier for the software version if there are no actual > > releases. > > FWIW, I used to believe the same but this changed my mind -- gnulib is a > rolling stable package with no releases: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069268#10 > > I believe versions numbers are for humans; incremental integers, dates > and possibly semantic versioning are useful ideas. I don't object to a > git commit identifier in a version number, but I also wouldn't want to > enforce it as a general rule. For gnulib I settled on recording the > full git commit identifier in debian/changelog instead.
I do think the commit ID is valuable. In case there isn't a friendly number, then the commit ID is the actual identifier of what you're running. But git commit IDs are 'random' and so they're useless for sorting purposes, which is essential when checking for a newer version and for `dpkg --compare-versions` to work. Thus adding the date is needed for that. But the date itself is only an *indication* of what you're actually running. > In case you make more than one snapshot per day, you can append a > snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1. > This should rarely be necessary. If a rule is proposed to Policy, then it needs to account for such a situation and should therefor require an incremental number, which again is needed for proper sorting/comparing. It's also better for (potential) tooling when the format is consistent. And I like consistency in general. Cheers, Diederik
signature.asc
Description: PGP signature
