On Thu, Jan 21, 2016 at 02:51:29PM +1000, Ben Woodcroft wrote: > > > On 12/01/16 19:26, Ludovic Courtès wrote: > >Ricardo Wurmus <rek...@elephly.net> skribis: > > > >>Should we also take some time to reconsider how we name unreleased > >>versions like arbitrary git commits? > >Let do that! > Lets. > >>So far we have been picking the latest release version (or “0.0.0” if > >>there hasn’t been any release) followed by “.” and either a date or a > >>guix-internal revision number, then again a “.” followed by part of the > >>commit hash. > >> > >>I’m afraid that we might accidentally introduce conflicts with future > >>release versions, e.g. when the latest release only uses two digits > >>(e.g. “0.1”) and we add a revision or a date (e.g. “0.1.1” or > >>“0.1.20160112”) and the next release and the next official release > >>switches to three digits (e.g. “0.1.1”). > >> > >>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? > > 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 ?
That sounds good to me. There was some discussion of how much of the hash to keep here: http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00136.html I like this method that I've seen in some of the packages, because it keeps the version tidy while preserving the full hash: --8<---------------cut here---------------start------------->8--- (define-public hello (let ((commit "e8e46123cfe62170a2f7f79db6b471b66ae36947")) (package (name "hello") (version (string-append "2.10-1" (string-take commit 8))) (source (origin (method git-fetch) (uri (git-reference (url "git://git.sv.gnu.org/hello.git") (commit commit))) (sha256 [...] --8<---------------cut here---------------end--------------->8--- > > ta > ben >
