Perfect! Applied. Many thanks Dave.
Tim.
On Wed, Apr 18, 2012 at 11:48:31AM +0100, Dave Mitchell wrote:
> On Fri, Mar 02, 2012 at 05:04:29PM +, Dave Mitchell wrote:
> > On Fri, Mar 02, 2012 at 03:23:30PM +, Dave Mitchell wrote:
> > > I'd be happy in principle, although some guidance would
On Fri, Mar 02, 2012 at 05:04:29PM +, Dave Mitchell wrote:
> On Fri, Mar 02, 2012 at 03:23:30PM +, Dave Mitchell wrote:
> > I'd be happy in principle, although some guidance would be welcome
>
> Also in particular, what needs to continue happening across an API
> change? Is it just that a
Am 02.03.2012 16:11, schrieb Tim Bunce:
[...]
> However, I'd still like to make the change. So I'm thinking it might be
> best to support *both* mechanisms for at least a few releases before
> removing the old one. The gives end users a "safe zone" where they
> can upgrade the DBI and then later up
On Fri, Mar 02, 2012 at 03:23:30PM +, Dave Mitchell wrote:
> I'd be happy in principle, although some guidance would be welcome
Also in particular, what needs to continue happening across an API
change? Is it just that a driver, compiled and installed against an old
DBI, must continue to work
On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote:
> On Fri, Feb 10, 2012 at 03:27:24PM +, Dave Mitchell wrote:
> I'm concerned that changing the API, and thus forcing all compiled
> drivers to be recompiled at the same time the DBI is installed,
> isn't worth the gain. Especially as dr
On Fri, Feb 10, 2012 at 03:27:24PM +, Dave Mitchell wrote:
>
> The second patch, which makes DBIS more efficient, is a lot more complex,
> and more likely to break things (especially as it's changing a bunch of
> macros that are directly #included by the DBD drivers. You may need to
> bump API
