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: [VOTE] APR versioning rules w.r.t. released snapshots
Date Tue, 15 Dec 2009 20:38:11 GMT
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.]

View raw message