Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B2FF1BC.7000808@rowe-clan.net>
Date: Mon, 21 Dec 2009 16:07:56 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Bojan Smojver <bojan@rexursive.com>
CC: Guenter Knauf <fuankg@apache.org>,
 APR Developer List <dev@apr.apache.org>
Subject: Re: [discuss] Releasing pre-release APR
References: <4B2FC35A.9030101@rowe-clan.net>  <4B2FCE13.7070105@apache.org>
 <1261430039.1981.19.camel@shrek.rexursive.com>
In-Reply-To: <1261430039.1981.19.camel@shrek.rexursive.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Bojan Smojver wrote:
> On Mon, 2009-12-21 at 20:35 +0100, Guenter Knauf wrote:
>> I think we need a way to distribute alpha releases, just same as what
>> we do with httpd. 
> 
> Why don't we just do what many other projects do - pronounce that for
> any odd minor release no versioning rules apply, whatsoever. So, if
> somebody links to, say 1.5 in the future, it's their own problem if
> things change in 1.6.

In conjunction with naming resources as -2.5 instead of -2, including the
libs and include directories, so that 2.5 is explicitly incompatible with
the 2.x series, while the 2.6 resources would all be named -2 (true binary
compatibility) this would make a lot of sense.  My personal preference is
to avoid disrupting the 1.x versioning policy.

It would also help if our apr.m4 suggested feature-detection macros would
only pick up this x.odd release on demand, and not pick up such versions
without the explicit autoconf flag to do so.