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: apr-config and apr-1-config
Date Fri, 02 Jul 2004 17:01:53 GMT
At 11:20 AM 7/2/2004, you wrote:
>> At 07:29 PM 7/1/2004, Greg Stein wrote:
>> >On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote:
>> >> If we leave it, and side-by-side installs are broken, this does not
>> >> like a good initial release point for 1.0 :(
>> >
>> >"for the moment"
>> >
>> >Joe said it *twice*. Was it that non-obvious?
>> No, it was obvious.  However another party is rolling what he hopes to be
>> the initial release on Friday, on his schedule.  So if we *release* on Fri
>> this would not be good.  If it gets fixed next week and we can hold the
>> release till next week, all would be lovely.
>> Competing interests - and my message wasn't directed at Joe or Graham
>Damn. Competing interests? So, no-one else wants to get 1.0 out teh door.
>Wow, must have been in dream land for a long, long time then...

Speed/Schedule of releasing 1.0 v.s. Completeness/Interoperability w/ 0.9.

I for one am glad you've put folks feet to the fire so to speak, and laid out
an ambitious plan for release of 1.0 this month :)

Sometimes, until you try to implement, what seemed just fine in a build
system turns out to be ineffective when confronted with rolling usable rpm's,
deploying side by side with previous versions, etc.  It wasn't until apr-1.0
that the apr/httpd side has ever really considered side-by-side installation
issues, since we need the legacy 0.9 for some time to support httpd 2.0,
and will need 1.0 installed and ready for httpd 2.1+, svn, jakarta-jk2 and
so forth.

Graham's RPM efforts have put a magnifying glass to every open parallel
install issue - I think it's wonderful that he created the perfect example
case whether he intended to, or not :)

>> who have been working hard at the rpm/parallel install issues.  It was
>> directed at David who was hoping (expecting?) to roll an RC3 candidate
>> today.
>Well, some form of explanation of the above would be more helpful than
>cryptic comments.

Sorry, it was my reaction to Greg's comments - which read (to me) that
he was saying yes - table this for now, release 1.0.0, install and clobber
the existing shared apr 0.9.5 install, then figure out how to get it right with
release 1.0.1.  That concerned me.

>1/10 on helpfulness.

I believe, with the possible exception of apr_finfo_t::ctime (and still asking
for feedback), that APR is code-complete API stable for 1.0.  With apr-iconv designated as
a mutable implementation detail of the public apr_xlate 
interface, that is not an issue either.  I spent no time in apr-util so I really
don't have an opinion either way.

If Graham's efforts, with Joe's useful feedback, produces a build system
which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied 
we finished APR 1.0.

I'd be very happy if we left apr-config alone (as 0.9), created apr-1-config
or apr-1.0-config with a symlink named apr-1-config, and let the consumers
attempt to use apr-[n..1]-config down to apr-config, based on what THEIR
application is targeted at and capable of supporting.  The version argument
solution to apr-config also sounds like it could solve the problem.


View raw message