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: Quick things, apr/apr-util releases
Date Tue, 15 Dec 2009 18:56:03 GMT
Ruediger Pluem wrote:
> On 15.12.2009 19:23, William A. Rowe Jr. wrote:
>> Joe Orton wrote:
>>> Clearly we aren't going to get agreement by repeating the same arguments 
>>> back at each other, so let's vote on this and move on to doing something 
>>> useful.
>> I've demonstrated the technical rational to this argument, you can't
>> demote a technical veto to an opinion through a vote.
>>
>> I completely agree that APR is not responsible for httpd's mess.  I'm only
>> pointing out that the vast majority install apr from a packager (no trouble)
>> or from an httpd package (therein lies the trouble).
> 
> Sorry but I don't get this. If there were some product lets call it Trouble
> Server that would ship always with recent apr 1.4.x snapshots or even trunk
> snapshots and would install them during its installation procedure,
> would that force us to cast the current trunk API in stone?

Is Trouble Server shipped from the Apache Software Foundation?

If not I'd think we would just loudly slap Trouble Server Project on the APR
home page, warning users of the problem, and otherwise ignore the mess they
create.

> Or take it one step further. I want to harm APR and each time there is an
> API change in trunk I publish a product that ships with this trunk snapshot,
> does this force us to burn another release number in APR?

If we do it to ourselves, yes.  I consider two votes on the 'vote' thread
entirely invalid, since they voted to release this APR in spite of the
technical objection and early warnings.

I'm worried if non-httpd people don't express an opinion on this thread, as
they are the ones most likely harmed.  The next httpd release is likely to
wipe out the previous apr/apr-util installed on the user's machine, giving
no harm, no foul for httpd's carelessness.  But packages relying on the
user to install apr and detecting if it's already present?  Bugger those.




Mime
View raw message