I'm not going to cast a vote here because I think the vote is a)
premature, b) not carried out in the proper forum.
If we assume that any part of APR that's bundled with httpd does not
constitute an APR release -- and note that we're talking about related
projects within the ASF, not some random pair of projects -- then httpd
has no business bundling unreleased APR bits in its release tarballs,
but should only used released APR versions and/or point at existing APR
tarballs.
I completely agree with Bill that it's entirely irrelevant whether a
release is named alpha or don't-touch or whatever; if it's in /dist,
it's a release. The only question is if it's also a release of APR or not.
Bill's concerns about not intercoursing users by breaking a released ABI
are valid.
Everybody else's responses that "it's an alpha" are ... at this time
indeterminate, and IMNSHO not subject to politics (i.e., voting) but to
technical arguments. "It's just a few users" is not a technical
argument, I think you'll all agree.
Specifically: if I build and install the APR from that bespoke httpd
tarball, what does apr-1-config --version say?
* If the answer is 1.4.0, the user will believe they just installed
an APR release.
* If the answer is 1.4.0-dev, then it's clearly a development
snapshot and all bets are off.
This is not about which project within the ASF released something; for
all I care, you guys can go to a gym with a boxing ring somewhere and
debate it out there. This is about user expectations. Httpd has a
different versioning policy, modules can and do get broken between minor
releases. APR's policy is stricter than that, and for example implies
that we can't fix a released, broken crypto API before APR-2.0.
Since we're both in the same ASF boat, we may want to keep this in mind
when solving the problem.
-- Brane
