[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Version numbers for VCS snapshots
From: |
Leo Famulari |
Subject: |
Re: Version numbers for VCS snapshots |
Date: |
Thu, 21 Jan 2016 01:22:51 -0500 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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 <address@hidden> 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
>
- New CLI syntax for package version, Ludovic Courtès, 2016/01/09
- Re: Version numbers for VCS snapshots, Ricardo Wurmus, 2016/01/21
- Re: Version numbers for VCS snapshots, Ludovic Courtès, 2016/01/21
- Re: Version numbers for VCS snapshots, Ricardo Wurmus, 2016/01/21
- Re: Version numbers for VCS snapshots, Ludovic Courtès, 2016/01/23
- Re: Version numbers for VCS snapshots, Ricardo Wurmus, 2016/01/23
- Re: Version numbers for VCS snapshots, Ludovic Courtès, 2016/01/24
- Re: Version numbers for VCS snapshots, Eric Bavier, 2016/01/21