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 improvementsThose 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: hu1.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...
Attachment:
signature.asc
Description: This is a digitally signed message part