Re: [Tracker] ANNOUNCE: tracker 0.9.31 released (unstable)

[Martyn Russell <martyn lanedo com>]

On 13/12/10 14:27, Michael Biebl wrote:
> 2010/12/13 Martyn Russell<martyn lanedo com>:
> > On 13/12/10 03:56, Michael Biebl wrote:
> > > 2010/12/10 Martyn Russell<martyn lanedo com>:
> > > >   * build: Binaries built now use *stable* named versions only (i.e. 0.10
> > > > not
> > > > 0.9)
> > >
> > > So, 0.9.31 is not declared stable yet, but you already use the stable
> > > version names. That's a bit confusing.
> > > Could you elaborate on this?
> >
> > Sure.
> >
> > > Do you expect no more API incompatible changes before the stable release?
> >
> > It's not really about that. We did this for a few reasons:
> >
> > - It just makes switching when we do a stable release that much easier and
> > less (potentially) problematic on the day.
>
> For the devel/unstable branch iirc the idea was to use an odd
> soversion, as a clear indication that the ABI can break anytime,
> without the soname being bumped.

Well, _version_ yes. Not really sure the soversion is strictly included 
in this. If you're using pkg-config, the soname is really not so relevant.

> Now you are using the "stable" soversion, even if the libs aren't yet
> declared stable. That's the bit I find confusing.

I see your point.

> And if 3rd party packages start using the stable soversion today, they
> can potentially break by future updates of tracker.
> That shouldn't happen.

I suppose that depends on if you just go by sonames and don't actually 
consider the version of the library. You could also argue that if you 
start using libtracker-sparql-0.12*.so in the next month or so that 
they're expected to break API/ABI from 0.10 (which is correct), but I 
would expect anyone that's using the 0.12 so files to know that they're 
using a development version and hence it can change. I guess there is no 
way then to know *when* an so is stable other than to look at the 
version of the package it comes in - which is your main issue here.

From my point of view, it just makes maintenance easier. Also we're 
planning the first stable release in the first week of January at this 
point so the renaming now isn't badly timed because we don't expect the 
API to change anyway.

> > > And on a completely different note, "make install" seems to install
> > > over 150Mb of data into /usr/share/tracker-tests here.
> >
> > They don't, If you build with --disable-functional-tests they shouldn't be
> > built or installed. I didn't know it was 150Mb though, that's quite
> > shocking. If the --disable-functional-tests doesn't do it, --disable-gtk-doc
> > definitely should.
>
> I tried --disable-functional-tests --disable-unit-tests now, and those
> files are no longer installed. Thanks for the hint.
>
> I'm still wondering though, if functional-tests being enabled by
> *default* is a good idea.

Probably not actually. I am happy to change this, Ivan and others, do 
you have a comment here?

--
Regards,
Martyn