You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2005/08/09 18:39:53 UTC
APR/APR-Util 1.2.0
Since apparently we require a release of APR-Util 1.2.0 to go along with
APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
that the APR-DBD interfaces are going to change in the very near future
so that they can support Oracle, does anyone see a problem with simply
removing the DBD portions of the code from 1.2.0 and leaving it till 1.3.0?
If there's no objection, I'll volunteer to do the work of extracting the
DBD code and being the release manager for 1.2.0.
-garrett
Re: APR/APR-Util 1.2.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 9, 2005 9:39:53 AM -0700 Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> If there's no objection, I'll volunteer to do the work of extracting the DBD
> code and being the release manager for 1.2.0.
Hey! Look, someone volunteering to do actual work. ;-)
*catch him, Pa!, before he runs away*
Sounds fine to me. -- justin
Re: APR/APR-Util 1.2.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Nick Kew wrote:
> Garrett Rooney wrote:
>
>> Since apparently we require a release of APR-Util 1.2.0 to go along
>> with APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the
>> fact that the APR-DBD interfaces are going to change in the very near
>> future so that they can support Oracle,
>
>
> Please see my post of Aug. 3rd. The likely changes will be fully
> back-compatible, so there's no reason not to exclude apr_dbd as-is
> from a new release.
>
Actually, I just replied to that, I'm not sure your proposed way forward
is in line with our versioning guidelines...
-garrett
Re: APR/APR-Util 1.2.0
Posted by Nick Kew <ni...@webthing.com>.
Garrett Rooney wrote:
> Since apparently we require a release of APR-Util 1.2.0 to go along with
> APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
> that the APR-DBD interfaces are going to change in the very near future
> so that they can support Oracle,
Please see my post of Aug. 3rd. The likely changes will be fully
back-compatible, so there's no reason not to exclude apr_dbd as-is
from a new release.
--
Nick Kew
Re: APR/APR-Util 1.2.0
Posted by Maxime Petazzoni <ma...@bulix.org>.
Hi,
* Garrett Rooney <ro...@electricjellyfish.net> [2005-08-09 09:39:53]:
> Since apparently we require a release of APR-Util 1.2.0 to go along with
> APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
> that the APR-DBD interfaces are going to change in the very near future
> so that they can support Oracle, does anyone see a problem with simply
> removing the DBD portions of the code from 1.2.0 and leaving it till 1.3.0?
>
> If there's no objection, I'll volunteer to do the work of extracting the
> DBD code and being the release manager for 1.2.0.
+1. Please don't forget the apr_date_parse_rfc() patch I submitted a
few days ago (I haven't got any feedback on it, btw) since it's fixing
the date sort in HTTPd's mod_mbox.
Thanks,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: APR/APR-Util 1.2.0
Posted by Brad Nicholes <BN...@novell.com>.
+1
Brad
>>> On Tuesday, August 09, 2005 at 10:39 am, in message
<42...@electricjellyfish.net>, Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> Since apparently we require a release of APR-Util 1.2.0 to go along
with
> APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
> that the APR-DBD interfaces are going to change in the very near
future
> so that they can support Oracle, does anyone see a problem with
simply
> removing the DBD portions of the code from 1.2.0 and leaving it till
1.3.0?
>
> If there's no objection, I'll volunteer to do the work of extracting
the
> DBD code and being the release manager for 1.2.0.
>
> -garrett
Re: APR/APR-Util 1.2.0
Posted by Graham Leggett <mi...@sharp.fm>.
Garrett Rooney wrote:
> Since apparently we require a release of APR-Util 1.2.0 to go along with
> APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
> that the APR-DBD interfaces are going to change in the very near future
> so that they can support Oracle, does anyone see a problem with simply
> removing the DBD portions of the code from 1.2.0 and leaving it till 1.3.0?
>
> If there's no objection, I'll volunteer to do the work of extracting the
> DBD code and being the release manager for 1.2.0.
+1
Regards,
Graham
--
Re: APR/APR-Util 1.2.0
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> Since apparently we require a release of APR-Util 1.2.0 to go along
> with APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the
> fact that the APR-DBD interfaces are going to change in the very near
> future so that they can support Oracle, does anyone see a problem with
> simply removing the DBD portions of the code from 1.2.0 and leaving it
> till 1.3.0?
>
> If there's no objection, I'll volunteer to do the work of extracting
> the DBD code and being the release manager for 1.2.0.
+1. I suggest you cut an 1.2.x branch off trunk and remove the apr_dbd
stuff on the branch only, that'll make further 1.2.x releases easier to
manage (since apr_dbd will have to wait for 1 3 anyway).
-- Brane
Re: APR/APR-Util 1.2.0
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Aug 09, 2005 at 09:39:53AM -0700, Garrett Rooney wrote:
> Since apparently we require a release of APR-Util 1.2.0 to go along with
> APR 1.2.0, and the only thing holding back APR-Util 1.2.0 is the fact
> that the APR-DBD interfaces are going to change in the very near future
> so that they can support Oracle, does anyone see a problem with simply
> removing the DBD portions of the code from 1.2.0 and leaving it till 1.3.0?
Without DBD there are no new interfaces on the trunk (that are
documented in CHANGES anyway), so the minor version bump would not be
necessary. But it would not violate the versioning rules, so I suppose
it's not a problem. It's just a bit odd, and it sucks to have the
apr-util release cycle beholden to the apr Netware build system.
joe