apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: apr-iconv 1.0
Date Fri, 25 Jun 2004 13:11:26 GMT
> At 06:30 PM 6/23/2004, David Reid wrote:
> >> I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 -
> >they
> >> are seperate subsets with their own set of issues.
> >>
> >> APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
> >> So no holdup of David's plans.
> >
> >Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc yet) but
> >needs to be released the same time as apr. Our 2 biggest users (httpd &
> >both use both (if that makes sense) so if we have apr 1.0, we have
> >1.0.
> Well, we can't ignore apr-iconv, apr-util has a dependency upon it for
> those platforms without a native port of iconv.


> But nothing precludes us from rolling up apr and dropping it upon the
> then rolling up apr-util and dropping that 1.0.0 in a separate step.

Sorry but that's a REALLY horrible precedent to set.

"Yeah APR is 1.0 but apr-util isn't..."

 I agree there is no need to tie the versioning, but I think for the initial
release of a "major" number they should be, so apr 2.0 and apr-util 2.0
should also be tied and released on the same date, whereas apr-util 1.1 can
go out anytime.

If people want to veto the candidate and force a retag with new code then
that's one thing. when I roll 1.0 it'll be all 3 repo's at the same time, as
will RC2.


> >Why does this hold up an apr-util 1.0 ? Please elaborate further.
> Because apr-util 1.0 consumes apr-iconv, at least for non-unix distros.
> >It does slightly annoy me that there has been a decent sized interval to
> >discsuss such issues and only now are they being brought up.
> Agreed - wish there were more eyes on the code.  My attention was solely
> focused on apr for the past weeks.  I think we very nearly have that
> so now i'm looking sideways at apr-util and how it could defy developer's
> expectations.  And the build breakage pointed out to me how wonky the
> current apr-iconv API really was (and mostly, my fault in the first place

Sorry you haven't had enough time (I know you've been busy), but there
aren't any votes for/against this and we (I) imposed a deadline to avoid
exactly this sort of drawn out delay.

If the answer to the question "does what we have now work" is "yes" then
apr-util 1.0 is good to go.

Sorry, but eventually you have to make a decision. I haven't seen anyone
state that what we have doesn't work, so I see no reason to hold things up
for "yet another code tweak at the 11th hour".


View raw message