apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: [discuss] Releasing pre-release APR
Date Mon, 21 Dec 2009 23:01:52 GMT
Branko Čibej wrote:
> William A. Rowe Jr. wrote:
>> 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.
>>   
> 
> Hey hey, slow down. Our versioning rules aren't all that useless. Yeah,
> it's hard to conform to them, but writing a generally useful portable
> runtime library is hard anyway, and these rules at least promise our
> users a measure of stability. For example, life in Subversion would be
> pure hell if APR's versioning rules were different.
> 
> Perfectly OK to invent safeguards that prevent people from being tripped
> by half-baked unreleased APIs, but to nuke the whole version numbering
> paradigm is nonsense.

I don't think Bojan actually suggests we nuke it.

The suggestion is that all n.even releases would be ABI stable.  n.odd
releases would be purely alpha- and beta-, with clear notices to the user
of what they are obtaining, and that updating is likely to break their
applications which are ./configure'd --with-apr-dev or some similar flag.

We could do the same thing with apr-2.2-dev-rc1, apr-2.2-dev-rc2 etc etc,
what Bojan suggests is that this .0-dev {rc tarball name} is all replaced
by n.odd.subver numbering, and that 2.1.3, for example, could coexist with
the 2.0 (or 2.2) release.  By default and without specific permission, any
apps using the apr.m4 detection macro would pick up the 2.0(2.2) stable.

What I suggest is that we consider what default guards should be put in
place so that people have to be very explicit about using 2.1.3 and know
full well that installing 2.1.4 is likely to break things :)


Mime
View raw message