Re: [gnome-db] Libgda modifications in CVS HEAD

["Gustavo R. Montesino" <grmontesino ig com br>]

On Sat, Jan 15, 2005 at 05:37:04PM +0100, Rodrigo Moya wrote:
> On Wed, 2005-01-12 at 23:56 -0200, Gustavo R. Montesino wrote:
> > On Tue, Jan 11, 2005 at 05:45:22PM +0100, Rodrigo Moya wrote:
> > > On Tue, 2005-01-11 at 15:17 +0100, Murray Cumming wrote:
> > > > On Tue, 2005-01-11 at 00:00 +0100, Rodrigo Moya wrote:
> > > > > On Mon, 2005-01-10 at 16:59 -0600, Daniel Espinosa wrote:
> > > > > > This change is API incompatible with the last version
> > > > > > of LibGDA, then is it correct for a version 1.x?
> > > > > > 
> > > > > no, API changes are not allowed in the 1.2 series. We might probably
> > > > > high the version number to 2.0 for that version
> > > > 
> > > > So this new libgda version will be parllel-installable with libgda-1.2.
> > > > 
> > > > So it needs a new pc file, and a different name for the libarary. Do you
> > > > plan to make those changes?
> > > > 
> > > > Unfortunately, you already use "2" in the library name, 
> > > > /opt/gnome210/lib/libgda-2.so
> > > > so you might want to choose a different even number for this new version
> > > > to avoid confusion.
> > > > 
> > > hmm, right. What about calling the lib libgda-2-0.so or something, and
> > > thus make it match with the libgda version number?
> > > 
> > > Or any other idea? Having libgda-2.0.pc and libgda-3.so might be a bit
> > > confusing.
> > 
> > Actually, I'm trying to make 1.0 and 1.2 parallel-installable on Debian,
> > and it doesn't seems so hard. It would be hand to have a configure
> > switch to choose a provider dir though (doing that is somewhere on my
> > TODO, but time...). I'm also not sure about how to handle configuration
> > and gconf yet. 
> > 
> > libgdasql also have the same soname (0) on 1.0 and 1.2 (BTW, they really
> > have the same API? It looks like it on surface, but I've made only
> > simple tests).
> > 
> no, there have been changes, but we forgot to up the soversion :(
> 
> It's now changed in HEAD.

Wouldn't be better to fix it in 1.2 branch also? Keeping two API-incompatible
libs with the same soname around sounds bad...

-- 
Gustavo R. Montesino
Debian Brasil - http://www.debianbrasil.org/