On Sat, 2016-12-10 at 16:36 +0100, Carlos Garnacho wrote:
[cut]
> I however think going from "odd minor number is unstable" to semver
> versioning with minor!=0 is going to be confusing...
Yes, changing it in the middle of a major release number is perhaps not
the brightest idea. True.
> 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.
This makes a lot of sense to me.
> If communicated properly, that'd at least allow us to have a single
> last/current stable release to care about most often, and the window
> to accumulate backwards compatible changes can be made variable based
> on urgency (situations like this don't come up often but you never
> know...),
Well, yes. Usually are security bugfixes just patch increments. But in
this case you solved the situation by adding sandboxing as a feature.
And then semver states that 'you added or changed functionality and or
APIs but didn't break backwards API compatibility' = minor increment.
> I wouldn't mind that this unstable window is still made to
> roughly match the 6 months gnome schedule though, and maybe release
> 2.[x+1] with whatever might accumulate in that period.
Sure. I would however not withhold from doing interim releases, and
assign one of those to the 6 month gnome release.
Not being a monorepo or monolithic architecture liker, I also don't
think that having a cadans dictated by something like gnome is
necessarily a good idea. But that clearly is just an opinion.
I think every project should be independent.
> How does that sound to you?
But yes, makes sense.
> 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:
> * property paths: last weekend got halfway with this \o/
> * graph management: for DROP GRAPH I think triggers will perform
Did ever something happen to cleaning up anonymous nodes of deleted
subjects/context, and or do reference counting on them (and clear them
once they reach zero references)?
If not then we are still leaking those in the db afaik. We always wanted
to do something about that.
> just fine, CREATE is also easy, for LOAD/MOVE/ADD it looks like we can
> unroll into specific updates.
> * the VALUES clause
> * the MINUS filter
> * CONSTRUCT/ASK/DESCRIBE
> * Removing or limiting the extensions we've gained on the way and
> are addressed in 1.1 (eg. accepting "AS var" as good, property paths
> greatly reduce the need for our property functions,... other
> extensions like FTS must stay of course)
>
> - Double checking ontology migration code, ensure it can handle weird
> ontology changes more or less elegantly.
You will have a lot, a lot of fun with that code :-)
> - Library-fying tracker-store, and separating ontology for good, so
> eg. an irc client wanting to store conversation logs privately can eg.
> do:
Yes! :) Want!
> connection_manager = tracker_open (".../.cache/my-app/private-store",
> "/usr/share/ontologies/nepomuk/nmo.ontology", cancellable, &error);
>
> And it gets a local database with just the relevant classes from the
> specified ontology. This might need a hardcoded basis though,
> xsd/rdf/nrl/dc/tracker at least. As long as that is properly
> documented I'm fine with it.
nod
> - 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.
nod
> 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...
> Does this sound sensible? matches reasonably with your own "Tracker as
> generic SPARQL endpoint" ideas?
Totally.
Philip
> > Sandboxing sounds to me like a new feature. Not just a bugfix.
> >
> > As Tracker gets used in ever increasing use-cases, ie. not only
> > desktops, I think our users want a clear version numbering policy. The
> > semver rules offer just that, and are compatible with API and ABI
> > changes and packaging formats like Debian and RedHat's.
> >
> >> * tracker-miner-fs: Fixed high CPU use when receiving many writeback
> >> notifications at once.
> >> * tracker-extract, libtracker-sparql, libtracker-miner: plug leaks
> >> * tests: cleanups and improvements
> >
> > Those two are worthy of a 1.11.2, yes. So I would have released a 1.12.0
> > containing the sandboxing, and a 1.11.2 with these two.
> >
> >> Translations: hu
> >
> > 1.11.2
> >
> >
> > Now, I understand that 1.10.1 was in need of a upgrade too, and
> > incrementing its version number to 1.11.0 would have conflicted with
> > existing releases under 1.11.x.
> >
> > What to do in that case, in my opinion, is to release a 1.12.0 coming
> > from 1.10.1 (instead of 1.10.2). And a 1.13.0 coming from 1.11.1
> > (instead of a 1.11.2). The release numbering just jumps over the
> > existing ones.
> >
> > I also think that, given that you are maintaining +3 simultaneous
> > releases, a gitflow setup could be useful (develop, master, hotfix/*,
> > release/* and feature/*).
>
> That is not by choice, believe me :), I would be more than happy if I
> had to maintain one single stable branch, then some distros stick to
> outdated stuff :(.
>
> Cheers,
> Carlos
>
> 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...
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
