You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2009/12/15 16:05:29 UTC
[VOTE] APR versioning rules w.r.t. released snapshots
Snapshots of the APR and APR-util 1.4.x trees have been distributed by
as part of the httpd 2.3.4 alpha release. Should the APR project treat
those snapshots as "releases" for versioning purposes? In other words,
should we ensure future APR/APR-util releases maintain source and binary
backwards compatibility with those snapshots as required by the
versioning guidelines, http://apr.apache.org/versioning.html?
Please vote:
[ ] Yes
[ ] No
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Guenter Knauf <fu...@apache.org>.
Joe Orton schrieb:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
[X] No
Gün.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2009-12-15 at 15:05 +0000, Joe Orton wrote:
> Should the APR project treat those snapshots as "releases" for
> versioning purposes?
Without actually casting a vote (because doing so seems to be
contentious in itself), I would say no. Generally speaking, APR folks
don't have control over what httpd folks bundle in their alpha releases.
So, APR should not care for decisions made by httpd. IMHO etc.
--
Bojan
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> On Tue, Dec 15, 2009 at 7:05 AM, Joe Orton <jo...@redhat.com> wrote:
>> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
>> as part of the httpd 2.3.4 alpha release. Should the APR project treat
>> those snapshots as "releases" for versioning purposes? In other words,
>> should we ensure future APR/APR-util releases maintain source and binary
>> backwards compatibility with those snapshots as required by the
>> versioning guidelines, http://apr.apache.org/versioning.html?
>>
>> Please vote:
>>
>> [ ] Yes
>> [ ] No
>>
>
> [x] No
You cannot ethically vote to release ASF software at one project and
declare it not-released at another project. That slight of hand renders
your vote invalid.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 15, 2009 at 7:05 AM, Joe Orton <jo...@redhat.com> wrote:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
> [ ] Yes
> [ ] No
>
[x] No
Thanks,
Paul
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Tollef Fog Heen <tf...@err.no>.
]] "William A. Rowe Jr."
I realise I'm somewhat late for the party here.
| Correct, it is internally labeled 1.4.0-dev. It is not externally (plainly
| visible to the user) as an apr-dev. The artifact is httpd-2.3.4-alpha-deps.tar
|
| > from the dev snapshot version bundled with httpd 2.3.4-alpha:
| > #define APR_MAJOR_VERSION 1
| > #define APR_MINOR_VERSION 4
| > #define APR_PATCH_VERSION 0
| > #define APR_IS_DEV_VERSION
Why not also embed the -dev in the soname so the version on disk will be
libapr-1-dev.so.0.4.0 (or whatever the last bits end up being)? This
would make it possible to install in parallel with what APR is actually
shipping as releases and not break httpd or the hypothetical
crypto-using application that's compiled against 1.4.1. It's a bit late
to do this to solve the current mess, but making sure that something
like that is set for non-committed ABI and APIs might be a good idea for
the future.
I don't know the exact mechanics you would use for windows and other
non-unixy systems, but I'm sure those responsible for those ports can
come up with something similar.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe Jr. wrote:
> Paul Querna wrote:
>
>> On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <br...@xbc.nu> wrote:
>>
>>> 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.
>>>
>> Exactly!
>>
>
> Correct, it is internally labeled 1.4.0-dev. It is not externally (plainly
> visible to the user) as an apr-dev. The artifact is httpd-2.3.4-alpha-deps.tar
>
>
>> from the dev snapshot version bundled with httpd 2.3.4-alpha:
>> #define APR_MAJOR_VERSION 1
>> #define APR_MINOR_VERSION 4
>> #define APR_PATCH_VERSION 0
>> #define APR_IS_DEV_VERSION
>>
>
> Unfortunately the APR versioning rules do not tell the developer not to compile
> against or link to -dev, while this gives the user no indication of what they
> are doing to their APR installation.
>
> Perhaps a future solution is to change the APR detection .m4 that we provide,
> to emit a loud ./configure results? E.g. warnings like
>
> You are building against an installed apr 1.4.1-dev.
> This is not a released version of the apr library.
>
> You are linking against a PRE-RELEASE version of apr-1.4.0,
> binary compatibility is not assured. Upgrade of this apr
> package should be expected to break this installed package.
>
> And on the side of APR's own ./configure --prefix=/old-apr-prefix
>
> YOU ARE REPLACING A MORE RECENT apr-1.4.1 with apr-1.4.0-dev. ARE YOU SURE?
>
> If these already existed, all of my objections would have been moot.
>
Oh, but such warnings can be retrofitted on a web page somewhere, in
this particular case I'd suggest the httpd pages since that's where the
release came from. We can add these warnings to configury right now and
before the real httpd and/or apr-1.4 releases.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
>
> (And maybe it's just me, but I prefer debugging a consistent abort on
> start-up than a random abort because of ABI mismatch).
True :)
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe Jr. wrote:
> Branko Čibej wrote:
>
>> Paul Querna wrote:
>>
>>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
>>> <wr...@rowe-clan.net> wrote:
>>>
>>>
>>>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>>>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>>>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>>>
>>>> Seems like a simple, sensible fix.
>>>>
>>> No, APR is a library, it has no ownership over stderr/stdout.
>>>
>> OK, stderr isn't a good idea, but APR can abort, right.
>>
>
> Well, if not stderr, then what? In this context (startup) stderr has a well
> defined meaning. I have no problem with my versions for HP/UX hacked with
> the [rejected] patch to allow HP libdld to emit a sensible message about what
> function could not be resolved by apr_dso(). There is no way to ask HP/UX
> for the contents of that message programatically. And by jove, libdld is ...
> wait for it ... a library! :)
>
> So for APR 2 I can see an optional behavior to allow/prohibit emitting any
> messages to stderr. That would cover both Paul's and other use cases.
>
> And apr_initialize() could certainly return APR_SUCCESS or a failure code
> that maps to 'wrong apr version' or some such, at APR 2.0.
>
> But abort() seems too unilateral, let the app author decide how pedantic
> to be, or how to exit gracefully, if there is no indication of what exactly
> was the problem?
>
How is aborting on memory allocation failure any different from aborting
on version mismatch? As for indication of failure -- by zeus, if
inspecting a core dump doesn't help, then nothing will. :) Especially if
we document that an abort in apr-initialize most likely means you
diddled with your library versions.
(And maybe it's just me, but I prefer debugging a consistent abort on
start-up than a random abort because of ABI mismatch).
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
> Paul Querna wrote:
>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>
>>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>>
>>> Seems like a simple, sensible fix.
>>
>> No, APR is a library, it has no ownership over stderr/stdout.
>
> OK, stderr isn't a good idea, but APR can abort, right.
Well, if not stderr, then what? In this context (startup) stderr has a well
defined meaning. I have no problem with my versions for HP/UX hacked with
the [rejected] patch to allow HP libdld to emit a sensible message about what
function could not be resolved by apr_dso(). There is no way to ask HP/UX
for the contents of that message programatically. And by jove, libdld is ...
wait for it ... a library! :)
So for APR 2 I can see an optional behavior to allow/prohibit emitting any
messages to stderr. That would cover both Paul's and other use cases.
And apr_initialize() could certainly return APR_SUCCESS or a failure code
that maps to 'wrong apr version' or some such, at APR 2.0.
But abort() seems too unilateral, let the app author decide how pedantic
to be, or how to exit gracefully, if there is no indication of what exactly
was the problem?
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
Paul Querna wrote:
> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>
>> Branko Čibej wrote:
>>
>>> William A. Rowe Jr. wrote:
>>>
>>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>>> against or link to -dev, while this gives the user no indication of what they
>>>> are doing to their APR installation.
>>>>
>>>>
>>> in that, you're correct. One would expect that developers do assume
>>> that, but it needs to be documented. Why not add that bit to
>>> versioning.html? It's quite a reasonable addition.
>>>
>>> For example, Subversion, which uses the exact same versioning rules as
>>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>>> about breaking the ABI to fix a bug between an RC and a release.
>>>
>> Should apr_initialize and friends be programmed to go 'bang' and drop out
>> with a stderr emit, if compiled against a x.y.0-dev release and run against
>> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>>
>> Seems like a simple, sensible fix.
>>
>>
>
>
> No, APR is a library, it has no ownership over stderr/stdout.
>
OK, stderr isn't a good idea, but APR can abort, right.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Branko Čibej wrote:
>> William A. Rowe Jr. wrote:
>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>> against or link to -dev, while this gives the user no indication of what they
>>> are doing to their APR installation.
>>>
>>
>> in that, you're correct. One would expect that developers do assume
>> that, but it needs to be documented. Why not add that bit to
>> versioning.html? It's quite a reasonable addition.
>>
>> For example, Subversion, which uses the exact same versioning rules as
>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>> about breaking the ABI to fix a bug between an RC and a release.
>
> Should apr_initialize and friends be programmed to go 'bang' and drop out
> with a stderr emit, if compiled against a x.y.0-dev release and run against
> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>
> Seems like a simple, sensible fix.
>
No, APR is a library, it has no ownership over stderr/stdout.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe Jr. wrote:
> Branko Čibej wrote:
>
>> William A. Rowe Jr. wrote:
>>
>>> Unfortunately the APR versioning rules do not tell the developer not to compile
>>> against or link to -dev, while this gives the user no indication of what they
>>> are doing to their APR installation.
>>>
>>>
>> in that, you're correct. One would expect that developers do assume
>> that, but it needs to be documented. Why not add that bit to
>> versioning.html? It's quite a reasonable addition.
>>
>> For example, Subversion, which uses the exact same versioning rules as
>> APR, regularly ships rlease candidates marked "-rc" and no-one worries
>> about breaking the ABI to fix a bug between an RC and a release.
>>
>
> Should apr_initialize and friends be programmed to go 'bang' and drop out
> with a stderr emit, if compiled against a x.y.0-dev release and run against
> x.y.*[1-9]? Or, at least a stderr warning at initialization time?
>
> Seems like a simple, sensible fix.
>
Yes, it does. A runtime version check in apr_initialize is an eminently
good idea. I'll see about adding one, like, right now.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
> William A. Rowe Jr. wrote:
>> Unfortunately the APR versioning rules do not tell the developer not to compile
>> against or link to -dev, while this gives the user no indication of what they
>> are doing to their APR installation.
>>
>
> in that, you're correct. One would expect that developers do assume
> that, but it needs to be documented. Why not add that bit to
> versioning.html? It's quite a reasonable addition.
>
> For example, Subversion, which uses the exact same versioning rules as
> APR, regularly ships rlease candidates marked "-rc" and no-one worries
> about breaking the ABI to fix a bug between an RC and a release.
Should apr_initialize and friends be programmed to go 'bang' and drop out
with a stderr emit, if compiled against a x.y.0-dev release and run against
x.y.*[1-9]? Or, at least a stderr warning at initialization time?
Seems like a simple, sensible fix.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe Jr. wrote:
> Unfortunately the APR versioning rules do not tell the developer not to compile
> against or link to -dev, while this gives the user no indication of what they
> are doing to their APR installation.
>
in that, you're correct. One would expect that developers do assume
that, but it needs to be documented. Why not add that bit to
versioning.html? It's quite a reasonable addition.
For example, Subversion, which uses the exact same versioning rules as
APR, regularly ships rlease candidates marked "-rc" and no-one worries
about breaking the ABI to fix a bug between an RC and a release.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <br...@xbc.nu> wrote:
>>
>> 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.
>
> Exactly!
Correct, it is internally labeled 1.4.0-dev. It is not externally (plainly
visible to the user) as an apr-dev. The artifact is httpd-2.3.4-alpha-deps.tar
> from the dev snapshot version bundled with httpd 2.3.4-alpha:
> #define APR_MAJOR_VERSION 1
> #define APR_MINOR_VERSION 4
> #define APR_PATCH_VERSION 0
> #define APR_IS_DEV_VERSION
Unfortunately the APR versioning rules do not tell the developer not to compile
against or link to -dev, while this gives the user no indication of what they
are doing to their APR installation.
Perhaps a future solution is to change the APR detection .m4 that we provide,
to emit a loud ./configure results? E.g. warnings like
You are building against an installed apr 1.4.1-dev.
This is not a released version of the apr library.
You are linking against a PRE-RELEASE version of apr-1.4.0,
binary compatibility is not assured. Upgrade of this apr
package should be expected to break this installed package.
And on the side of APR's own ./configure --prefix=/old-apr-prefix
YOU ARE REPLACING A MORE RECENT apr-1.4.1 with apr-1.4.0-dev. ARE YOU SURE?
If these already existed, all of my objections would have been moot.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
Paul Querna wrote:
>> 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.
>>
>
> Exactly!
>
> from the dev snapshot version bundled with httpd 2.3.4-alpha:
> #define APR_MAJOR_VERSION 1
> #define APR_MINOR_VERSION 4
> #define APR_PATCH_VERSION 0
> #define APR_IS_DEV_VERSION
>
In that case, I think there's nothing more to discuss. Let's fix what
needs to be fixed, and release a proper APR-1.4.0 in time for the real,
non-alpha httpd release.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 15, 2009 at 12:59 PM, Branko Čibej <br...@xbc.nu> wrote:
> 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.
Exactly!
from the dev snapshot version bundled with httpd 2.3.4-alpha:
#define APR_MAJOR_VERSION 1
#define APR_MINOR_VERSION 4
#define APR_PATCH_VERSION 0
#define APR_IS_DEV_VERSION
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
>
> By the way, if the answer turns out to be "no", then we can do the
> cryptoapi changes that were discussed in another thread for 1.4; and I
> was made aware of a patch to make pools friendlier to long-lived
> multithreaded applications which would be a nice-to-have (conceptually)
> in the 1.x series.
One makes sense, but the second doesn't. If we are adding functions, great,
but I didn't think that was the scope.
The conceptual change I'd like to work towards for 1.5.0 is an extention
of the max free pool setting. Take this one step further to track max
fragmentation of a specific pool before the pool is reaped and reallocated
as a single contiguous block.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Branko Čibej <br...@xbc.nu>.
Joe Orton wrote:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
> [ ] Yes
> [ ] No
>
By the way, if the answer turns out to be "no", then we can do the
cryptoapi changes that were discussed in another thread for 1.4; and I
was made aware of a patch to make pools friendlier to long-lived
multithreaded applications which would be a nice-to-have (conceptually)
in the 1.x series.
-- Brane
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Paul Querna <pa...@querna.org>.
On Tue, Dec 15, 2009 at 12:38 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> [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.]
>
http://svn.apache.org/viewvc//labs/badca/
BadCA hasn't been updated in 2 years, and was never ported to the APR
Crypto interfaces. (best laid plans of mice and men, etc)
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.]
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Dec 15, 2009 at 02:00:00PM -0500, William Rowe wrote:
> Joe Orton wrote:
> > On Tue, Dec 15, 2009 at 03:05:29PM +0000, Joe Orton wrote:
> >> [ ] Yes
> >> [X] No
> >
> > I vote no: what other ASF projects ship has no bearing on API
> > commitments made by the APR project.
>
>
> You cannot ethically vote to release ASF software at one project and
> declare it not-released at another project. That slight of hand renders
> your vote invalid.
Say *what* now? This is getting silly. In case it is unclear to
anybody else voting, I am not asking you to vote on whether the httpd
alpha is a release of the ASF. I'd hope the answer to that question was
obvious to everybody.
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.
I'm sorry if the wording of the vote didn't make that clear enough. If
any voter was not clear about this when voting, please reconsider your
position.
Regards, Joe
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Tue, Dec 15, 2009 at 03:05:29PM +0000, Joe Orton wrote:
>> [ ] Yes
>> [X] No
>
> I vote no: what other ASF projects ship has no bearing on API
> commitments made by the APR project.
You cannot ethically vote to release ASF software at one project and
declare it not-released at another project. That slight of hand renders
your vote invalid.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Dec 15, 2009 at 03:05:29PM +0000, Joe Orton wrote:
> [ ] Yes
> [X] No
I vote no: what other ASF projects ship has no bearing on API
commitments made by the APR project.
Regards, Joe
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
>
> We disagree on whether or not the httpd 2.3.4 prereqs tarball
> constitutes an APR release. Leave it at that.
Actually we don't disagree. Its an ASF release and not an APR release,
and we all agree on that. I suggest that it's trivial to work around
binary compatibility in *most* respects, e.g. DTRACE maintainer macros
excepted, and this becomes a silly-vote thread of the people who had
championed the release.
You asked, and I answered, that it's perfectly sane to offer some
snapshots as the reference of the perhaps-to-be-released API in our
/dev/dist/ area, etc. This was before the ASF /dist/ release occured.
There were very trivial ways to satisfy my early objections rather than
steamroll over them. And now we have specific applications where that
release now creates 'headaches' and disruption for the users of APR.
> It is not helpful in
> any way to refer to my vote as unethical or as a slight of hand.
It is simply contradictory and inconsistent. I maintain voting to this
contraction is invalid. But more importantly, I am looking forwards to
hearing the opinions of those who didn't already have this argument, as
they are the ones who had nothing to do with the anticipated state of the
user's machines. Are they satisfied testing for and excluding 1.4.0-dev,
and having their app break if the user installs httpd-2.3.4? None of the
folks who were part of this thread have that answer.
I am sorry if 'unethical' was an overly-harsh way of answering this vote.
Better yet, let my vetos stand and let me demonstrate that the workaround
is trivial, rather than pursuing such a thread, and disrupting APR development.
Where the workaround is not possible, I'm either going to concede that 1.5.0
resolves the ambiguity or we are living with the problem with proper cautions
to the users at apr.apache.org/httpd.apache.org.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Dec 15, 2009 at 1:58 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
>> On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton <jo...@redhat.com> wrote:
>>> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
>>> as part of the httpd 2.3.4 alpha release. Should the APR project treat
>>> those snapshots as "releases" for versioning purposes? In other words,
>>> should we ensure future APR/APR-util releases maintain source and binary
>>> backwards compatibility with those snapshots as required by the
>>> versioning guidelines, http://apr.apache.org/versioning.html?
>>>
>>> Please vote:
>>>
>>> [ ] Yes
>>
>> [X] No
>
> You cannot ethically vote to release ASF software at one project and
> declare it not-released at another project. That slight of hand renders
> your vote invalid.
We disagree on whether or not the httpd 2.3.4 prereqs tarball
constitutes an APR release. Leave it at that. It is not helpful in
any way to refer to my vote as unethical or as a slight of hand.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton <jo...@redhat.com> wrote:
>> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
>> as part of the httpd 2.3.4 alpha release. Should the APR project treat
>> those snapshots as "releases" for versioning purposes? In other words,
>> should we ensure future APR/APR-util releases maintain source and binary
>> backwards compatibility with those snapshots as required by the
>> versioning guidelines, http://apr.apache.org/versioning.html?
>>
>> Please vote:
>>
>> [ ] Yes
>
> [X] No
You cannot ethically vote to release ASF software at one project and
declare it not-released at another project. That slight of hand renders
your vote invalid.
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton <jo...@redhat.com> wrote:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
> [ ] Yes
[X] No
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Nick Kew <ni...@apache.org>.
On 15 Dec 2009, at 15:05, Joe Orton wrote:
> Please vote:
>
> [ ] Yes
> [ ] No
[x] No
The httpd distros (at least those with package managers) have been
weaned off bundling APR. Time for httpd itself to catch up.
In any case, this is not the responsibility of APR.
--
Nick Kew
Re: [VOTE] APR versioning rules w.r.t. released snapshots
Posted by Ruediger Pluem <rp...@apache.org>.
On 15.12.2009 16:05, Joe Orton wrote:
> Snapshots of the APR and APR-util 1.4.x trees have been distributed by
> as part of the httpd 2.3.4 alpha release. Should the APR project treat
> those snapshots as "releases" for versioning purposes? In other words,
> should we ensure future APR/APR-util releases maintain source and binary
> backwards compatibility with those snapshots as required by the
> versioning guidelines, http://apr.apache.org/versioning.html?
>
> Please vote:
>
> [ ] Yes
> [ ] No
>
>
[X] No
Regards
Rüdiger