One of the reasons we have done this (patch the head only) is to
decouple the release of the driver from releases of the server.
Previously we have run into the situation where we were freezing code
because of a server code freeze. This caused alot of patches to be lost,
and momentum to be lost by many people who used to contribute to the
driver.
By de-coupling the driver and letting it evolve on it's own time table
we are free to apply patches whenever they are available.
Also there really isn't a relationship between driver development and
server development. What I mean to say is if the server improves the
query analyzer it has no effect on the driver. However sometimes there
is a correlation, for instance the server side caching of statements, or
schema's.
From my POV, we are better to not be coupled to server releases. However
I do understand the need to back patch sometimes.
Dave
On Tue, 2002-12-24 at 13:23, Daniel Serodio wrote:
> On Tue, 2002-12-24 at 15:57, Kris Jurka wrote:
> >
> > On 23 Dec 2002, Dave Cramer wrote:
> >
> > > BTW, I only apply to the HEAD, we have never patched to the current
> > > version. Barry and I have talked about it recently, obviously you think
> > > this is "abnormal". What are your opinions about it?
> > >
> >
> > This means that the driver we ship with 7.3.0 will be exactly the same as
> > 7.3.1 and 7.3.2 and so on. The .0 release of the server and the driver
> > will generally bring about the discovery of bugs in both. The server bugs
> > are fixed and a new release is put out .1, but the driver bugs are only
> > fixed in HEAD and our only advice is to run a driver from CVS head. This
> > is something our users don't want to do because it requires a cvs checkout
> > and running untested code. I think the policy for the driver should match
> > that for the server: new features go into HEAD while bug fixes go into
> > both the stable and development branches.
> >
> > Kris Jurka
>
> I vote for backporting bugfixes to the stable branch, like Debian Stable
> does.
--
Dave Cramer <Dave@micro-automation.net>