From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-36022-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1M64SR-0008S9-QF
for garchives@archives.gentoo.org; Mon, 18 May 2009 15:08:51 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id CF7ABE02EB;
Mon, 18 May 2009 15:08:50 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id AFA5AE02EB
for <gentoo-dev@lists.gentoo.org>; Mon, 18 May 2009 15:08:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 61099654EC
for <gentoo-dev@lists.gentoo.org>; Mon, 18 May 2009 15:08:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -0.757
X-Spam-Level:
X-Spam-Status: No, score=-0.757 required=5.5 tests=[AWL=0.775,
BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CPrMJFMXhaen for <gentoo-dev@lists.gentoo.org>;
Mon, 18 May 2009 15:08:44 +0000 (UTC)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTP id 90E9D6525A
for <gentoo-dev@gentoo.org>; Mon, 18 May 2009 15:08:43 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1M64SD-0002xR-Ji
for gentoo-dev@gentoo.org; Mon, 18 May 2009 15:08:37 +0000
Received: from 91.84.77.8 ([91.84.77.8])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Mon, 18 May 2009 15:08:37 +0000
Received: from slong by 91.84.77.8 with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Mon, 18 May 2009 15:08:37 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Steven J Long <slong@rathaus.eclipse.co.uk>
Subject: [gentoo-dev] Re: GLEP 55 updated
Date: Mon, 18 May 2009 16:07:20 +0100
Organization: Friendly-Coders
Message-ID: <12688336.dTPDegVI1m@news.friendly-coders.info>
References: <d77765540905170856wa882914ica3dc4698c03bc96@mail.gmail.com> <7c612fc60905170920k22189731i2540514e24e60959@mail.gmail.com> <18960.18295.65849.57779@a1ihome1.kph.uni-mainz.de> <4A104BCE.7000001@gentoo.org> <4A107F05.7020001@gentoo.org> <20090517222016.3164b564@snowmobile> <4A1089E6.7070909@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 91.84.77.8
Sender: news <news@ger.gmane.org>
X-Archives-Salt: 0ea8bb83-962e-4807-bf2d-1e11fb12221b
X-Archives-Hash: 91b0b3917837f27f08003a6d7ea1a553
Joe Peterson wrote:
> Ciaran McCreesh wrote:
>>> 3. "Extend versioning rules in an EAPI - for example, addition of the
>>> scm suffix - GLEP54 [1] or allowing more sensible version formats like
>>> 1-rc1, 1-alpha etc. to match upstream more closely."
>>> Apart from GLEP54, I believe our versioning scheme works reasonably
>>> well. I don't see any need to match upstream more closely. I'd rather
>>> like to keep the more uniform way of handling suffixes like rc and
>>> alpha, that we have now.
>>
>> Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.
>
> I actually like the current format in that it does *not* allow "-" in
> the version. For example, pkg-2.3.1_rc5 makes it clear that the string
> from "2" to "rc5" is the version. If were were to allow pkg-2.3.1-rc5,
> this could get visually confusing (looks a bit like pkg-2.3.1-r5). In
> this case, *less* flexibility and more strict rules serve a good
> purpose, I think.
>
Agreed; the purpose of an internal format specification is not to allow
NN variants on a theme all over the place. It should nail things
down to ONE variant which everybody can collaborate around.
I missed the clamour of developers complaining about this oh-so-burdensome
restriction that they've been dealing with for at least 5 years. Until I see
that happening independently of this current hooha, I'm going to consider
this 'reason' to be yaf "straw man".
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)