Re: [Tracker] Fwd: tracker 1.11.2

[Sam Thursfield <ssssam gmail com>]

Hi!

On Sat, Dec 10, 2016 at 3:36 PM, Carlos Garnacho <carlosg gnome org> wrote:
> Although following its own version numbers, Tracker has been following
> lately the gnome schedule. I came to think lately (most nominally,
> when rolling this last bunch of tarballs), that the gnome schedule is
> indeed too fast paced for Tracker, while we've most often respected
> backwards compatibility quite thoroughly. eg. there's distros shipping
> 1.8 because that's what came out with gnome 3.20, while 1.10 is a
> qualitatively better drop-in replacement.
>
> I however think going from "odd minor number is unstable" to semver
> versioning with minor!=0 is going to be confusing... I will suggest
> the following plan:
>
> - Finish this 1.11.x/1.12 cycle
> - Sticking to 1.12.x for as long it's needed while
> - Gearing to a Tracker 2.x that switches to using semver approach to
> communicate API/ABI changes.

I like this plan.

> I'll also take the opportunity to introduce to the ML the "roadmap"
> that's been shaping up in my head for 2.x:
>
> - Getting as close to supporting the full sparql 1.1 spec as possible
> in libtracker-data:
> ...

Agreed

> - Double checking ontology migration code, ensure it can handle weird
> ontology changes more or less elegantly.

sounds good, but is this actually possible? I thought we found that it
was too hard to really do this well, and it'll be quite a bit of
effort

> - Library-fying tracker-store, and separating ontology for good ....

Yes!

> - And of course, keep dbus-based implementations around, I guess we
> can't move too far from nepomuk there, as it's already the implicit
> contract between miners and all the surrounding ecosystem.
>
> However would be great to have the tracker-store executable be more
> generic, so you can make it claim a different dbus name, write to a
> different location, construct the database using a different
> ontology...

Yes.

> PS. I haven't forgotten the "big rip" thread, nor the "Resource table
> fills up with UUIDs" from further in the past, need to get back to
> those...

One other thing to throw out here since we're on the subject of a
roadmap, I don't have strong opinion on if/when this is adopted but
I've been working on new build instructions using Meson:
<https://git.gnome.org/browse/tracker/log/?h=wip/sam/meson>. They're
maybe 75% complete at this point.

Sam