Ben Woodcroft <b.woodcr...@uq.edu.au> writes: > On 12/01/16 19:26, Ludovic Courtès wrote: >> Ricardo Wurmus <rek...@elephly.net> skribis: >> >>> Would it make sense to separate our version identifier from the actual >>> release version with a different character than “.”? Or should this be >>> discussed elsewhere as it hasn’t anything to do with how we specify >>> versions on the command line? >> Probably. Debian, for instance, uses “2.0.11-9” where “9” denotes the >> 9th package revision of upstream version “2.0.11”. We could probably >> use that convention. >> >> In a previous discussion on this topic, I suggested that we should have >> such a revision number instead of just “x.y.COMMIT”. The extra >> monotonically-increasing revision number is needed to allow upgrades to >> work as expected. >> >> So, a Git snapshot’s version number could be: >> >> 2.0.11-3.deadbeef >> ^ ^ ^ >> | | `— upstream commit ID >> | | >> | `—— 3rd Guix package revision >> | >> latest upstream version >> >> The next snapshot would be: >> >> 2.0.11-4.cafeefac >> >> WDYT? > I can't see anything wrong with this myself. Is this accepted policy now?
I think this is a good policy to follow. So far we didn’t always use “-” to separate the upstream version from the revision + commit ID (or did only I do this wrong?). Some packages use “.”, which is what prompted me to ask for clarification. > Also, is the convention for unreleased software to take 0.0.0 as the > version as you suggest Ricardo e.g. 0.0.0-1.deadbeef ? I think this is reasonable. It’s rather unusual for software to be released as “0.0.0”, so I don’t think we need to worry about this. Even then we could just update the Guix package revision number to force an update. ~~ Ricardo
