On Sun, 01 Dec 2024 12:58:41 +0100 Jonas Smedegaard <d...@jones.dk> wrote: > On Thu Nov 28, 2024 at 10:44 AM CET, Simon Josefsson wrote: > > 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. > > I have tried this approach, and ended in situations where the git hash > was directly damaging: Imagine the above, but with a random hash instead > beginning with "1", e.g. 0.0~git20130606.2.b00ec39-1 coming after > 0.0~git20130606.1dffba21-1. That won't work. > [...] > > A version number *must* be not only unique but also incremental. A > git has is fundamentally not incremental, so poses a real risk of > getting in the way of constructing robust version numbers. And for > which benefit? Ensuring uniqueness? It is already unique that > 0.0~git20130606-1 and 0.0~git20130606.2-1 are the first and second > Debian snapshot issued that day, and to know what that corresponds to > upstream, you already need not only a git hash but also a git repo URI. > > I have come to view git hash in version string as a vanity identifier, > similar to "clarifying" paranthetical notes in OpenPGP identifiers > like "Jonas Smedegaard (Debian work) <d...@jones.dk>". > > Please let's discourage (not promote) those, and certainly let's not > bake them into Policy. >
I agree that forcing the date-commit format is not the way to go imo.It's not that often the case that a packages with no releases has two commits in a day,
and I doubt that most packagers would run into this.While I agree on the 0.0~git prefix I'd argue that the date is sufficient. As pointed out
it sorts with dpkg and if someone is really wants to know which exact commit they have they can get it from
salsa.Recommending the data+hash format is certainly a not a bad idea, though I really think date as single identifier suffices.
best, werdahias
OpenPGP_0xECBEDBB607B9B2BE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
