]] 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
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
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 :)
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
On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton jor...@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
On Tue, Dec 15, 2009 at 03:05:29PM +, 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
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
On Tue, Dec 15, 2009 at 7:05 AM, Joe Orton jor...@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
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
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)
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
Jeff Trawick wrote:
On Tue, Dec 15, 2009 at 10:05 AM, Joe Orton jor...@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
Paul Querna wrote:
On Tue, Dec 15, 2009 at 7:05 AM, Joe Orton jor...@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
Joe Orton wrote:
On Tue, Dec 15, 2009 at 03:05:29PM +, 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
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 jor...@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
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
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
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
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
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
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
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
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
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
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
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.
On Tue, 2009-12-15 at 15:05 +, 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
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
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.]
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
30 matches
Mail list logo
