Joe Orton wrote: > > I am asking people to vote on whether the APR project considers that > release of the ASF to be significant for APR library versioning > purposes. That is a decision which can be made by the APR project, as > we agreed in the other thread.
And I've spelled out why this discussion is so silly. Irrespective of "rules", there are conventions. APR has a convention for testing if the version is appropriate. httpd release has set down the benchmark to use for that test. You discount that users don't simply hit http://www.apache.org/dist/httpd/ and download the most-current thing they see. Especially those who are early adopters/bleeding edge sorts of fans. It's a really *stupid* debate, and even stranger when the two strongest voices for versioning, compatibility and expectations chime in on the side of violating the principal of least surprise. But what is more aggravating is that it's TRIVIAL to work around the actual compatibility issues. I just pointed out how to do so, and spare us a more bogus implementation of apr_crypto_error, and offered to solve the apr_crypto_t partial-unwrapping puzzle for incomplete types. I conceded to Paul that keeping compatibility has to fall within reason. Solving the DTRACE mess will fall outside of that reason, but I don't expect anyone deploying DTRACE is doing so arbitrarily for the reasons he pointed out in the thread. On the bigger picture of "does httpd project bind apr's decisions?" you cannot even suggest that three APR committers voting to ship something that is based on pre-release APR, disruptive to users, reflects well on predictability in the APR library. If you want to start a *useful* vote thread, start one which formally modifies the versioning contract, and let's put an MMN in there or introduce other mechanics for determining the presence or absence of API's. That would solve this and many more problems we and our users struggle with, trying to advance the library without disrupting users' installations. Or solve the question of how the APR project will put forward alpha or beta or even formalize the snapshot (vs. release) process for the wider community to then review the API. How do we do last-calls? These would all be worthwhile discussions that would improve adoption of APR, instead of lowering confidence in its adoption. [You are wrong, FWIW. BadCA was one of the first adopters of the original crypto interfaces. I don't know that it was ported to the current iteration of the crypto interface.]
