apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: [discuss] Releasing pre-release APR
Date Tue, 22 Dec 2009 09:09:45 GMT
Bojan Smojver wrote:
> On Mon, 2009-12-21 at 17:01 -0600, William A. Rowe Jr. wrote:
>> I don't think Bojan actually suggests we nuke it.
> No, no nuking at all. Just bit of skipping.
>> 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.
> Yep, something like that. In other words, if we have say 1.8 released
> and we are working towards 1.10, then anything in 1.9 is completely
> API/ABI unstable and relying on it being present in 1.10 is a gamble. Of
> course, the relationship between 1.8 and 1.10 would still obey the same
> rules as we now have for say 1.3 to 1.4.

-1 ... I've always found that approach a bit weird. There's no
functional difference between 1.(oddx).y and 1.x.y-dev. It makes
marginal sense to use the odd/even approach in projects like the Linux
kernel where one expects to have dozens of intermediate development
"releases" that do need to be differentiated. APR is quite a bit smaller
and there's less flux, so changing the versioning scheme would cause
unnecessary pain to users who're already well accustomed to it. Besides,
I'm aware of quite a few projects who use the same versioning scheme and
refer explicitly to our versioning.html file; if we change that without
making a huge announcement, we intercourse those projects too. So I
agree with Rüdiger that we can't actually change what APR version
numbers mean before 2.0.

If we /do/ happen to make a 1.x.y-dev pre-release that doesn't fly and
we're concerned about breaking early adopters, and want to really
differentiate between different releases, we're allowed to do a
1.x.y+1-dev without a 1.x.y release in between. This is going to be rare
once the -dev and non-dev libraries become mutually unlinkable, so I
really wouldn't worry about burning too many version numbers. They're
free, after all.

-- Brane

View raw message