From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Woodcroft Subject: Re: Version numbers for VCS snapshots Date: Thu, 21 Jan 2016 14:51:29 +1000 Message-ID: <56A063D1.80608@uq.edu.au> References: <874mem8mwx.fsf@gnu.org> <8737u344ov.fsf@elephly.net> <87twmjp2qs.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7Dj-0007rD-Fa for guix-devel@gnu.org; Wed, 20 Jan 2016 23:51:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aM7De-0000Ac-L8 for guix-devel@gnu.org; Wed, 20 Jan 2016 23:51:43 -0500 In-Reply-To: <87twmjp2qs.fsf_-_@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , Ricardo Wurmus Cc: guix-devel@gnu.org On 12/01/16 19:26, Ludovic Court=C3=A8s wrote: > Ricardo Wurmus 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 =E2=80=9C0.= 0.0=E2=80=9D if >> there hasn=E2=80=99t been any release) followed by =E2=80=9C.=E2=80=9D= and either a date or a >> guix-internal revision number, then again a =E2=80=9C.=E2=80=9D follow= ed by part of the >> commit hash. >> >> I=E2=80=99m afraid that we might accidentally introduce conflicts with= future >> release versions, e.g. when the latest release only uses two digits >> (e.g. =E2=80=9C0.1=E2=80=9D) and we add a revision or a date (e.g. =E2= =80=9C0.1.1=E2=80=9D or >> =E2=80=9C0.1.20160112=E2=80=9D) and the next release and the next offi= cial release >> switches to three digits (e.g. =E2=80=9C0.1.1=E2=80=9D). >> >> Would it make sense to separate our version identifier from the actual >> release version with a different character than =E2=80=9C.=E2=80=9D? = Or should this be >> discussed elsewhere as it hasn=E2=80=99t anything to do with how we sp= ecify >> versions on the command line? > Probably. Debian, for instance, uses =E2=80=9C2.0.11-9=E2=80=9D where = =E2=80=9C9=E2=80=9D denotes the > 9th package revision of upstream version =E2=80=9C2.0.11=E2=80=9D. 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 =E2=80=9Cx.y.COMMIT=E2=80=9D. T= he extra > monotonically-increasing revision number is needed to allow upgrades to > work as expected. > > So, a Git snapshot=E2=80=99s version number could be: > > 2.0.11-3.deadbeef > ^ ^ ^ > | | `=E2=80=94 upstream commit ID > | | > | `=E2=80=94=E2=80=94 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=20 version as you suggest Ricardo e.g. 0.0.0-1.deadbeef ? ta ben