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

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

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?


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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]