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. Then you could introduce a special delimiter, essentially abusing the real purposes of those delimiters, e.g. 0.0~git20130606~+1dffba21-1 and 0.0~git20130606.2~+b00ec39-1. But then you may (like I did) run into your chosen "semaphor" clashing in similar way, but this time baked into helper tools that are difficult to bypass for that rare occasion that you are in just now: See section on "grouped package" in man page for uscan for the real existing potential for clash I ran into. 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
