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.
