GNOME Bugzilla – Bug 715088
build: support tracker 0.18
Last modified: 2016-03-31 13:22:07 UTC
Tracker, as usually, renamed the .pc file for 0.18. Let's support it.
Created attachment 261328 [details] [review] build: support tracker 0.18
<zeenix> is the tracker api changing w/ every minor release? <zeenix> if not, i don't see why the pc file need to change version <zeenix> juergbi: ^ <phako> talked with martyn about this, but I forgot the reason tbh <juergbi> it's probably high time that we guarantee API for longer, yes <juergbi> i'm not much involved anymore, though, so it's not my call Martyn?
(In reply to comment #2) > <zeenix> is the tracker api changing w/ every minor release? > <zeenix> if not, i don't see why the pc file need to change version > <zeenix> juergbi: ^ > <phako> talked with martyn about this, but I forgot the reason tbh > <juergbi> it's probably high time that we guarantee API for longer, yes > <juergbi> i'm not much involved anymore, though, so it's not my call > > Martyn? I've been wondering if we should do a 1.0 release or something like that. Not much is changing lately in the code base other than fixing deprecation in GLib and adding support for the odd file format. We're also improving the portability at times, but not much major work is going on, things are reasonably stable lately. I need to take a look before really answering this question properly for 0.16 --> 0.18 to be fair. APIs do change between minor versions like 0.14 --> 0.16 traditionally or if new functionality is quite disruptive and may cause unknown regressions. It's not just about the API/ABI but also features and required upgrades (e.g. GConf --> GSettings). I am happy to make 0.17 a 1.0 release. Technically, I've always followed the GLib/GTK+ release approach closely. I would like to know what the team think, mostly this is from: Juergbi, pvanhoof, garnacho and ssam2. Thoughts? Not sure I answered your question zeenix :)
(In reply to comment #3) > (In reply to comment #2) > > <zeenix> is the tracker api changing w/ every minor release? > > <zeenix> if not, i don't see why the pc file need to change version > > <zeenix> juergbi: ^ > > <phako> talked with martyn about this, but I forgot the reason tbh > > <juergbi> it's probably high time that we guarantee API for longer, yes > > <juergbi> i'm not much involved anymore, though, so it's not my call > > > > Martyn? > > I've been wondering if we should do a 1.0 release or something like that. Not > much is changing lately in the code base other than fixing deprecation in GLib > and adding support for the odd file format. We're also improving the > portability at times, but not much major work is going on, things are > reasonably stable lately. > > I need to take a look before really answering this question properly for 0.16 > --> 0.18 to be fair. Sure, we have a patch for now anyway. :) > I am happy to make 0.17 a 1.0 release. Technically, I've always followed the > GLib/GTK+ release approach closely. Huh? They are not changing their .pc file version on every minor release, e.g gtk+-3.0.
(In reply to comment #4) > (In reply to comment #3) > > I am happy to make 0.17 a 1.0 release. Technically, I've always followed the > > GLib/GTK+ release approach closely. > > Huh? They are not changing their .pc file version on every minor release, e.g > gtk+-3.0. I never said exactly. About the .pc file, I don't feel strongly about how this is done or if we change that and it's a minor detail. I agree it's a pain in the arse for some people but since we've never had a major release (e.g. 1.0, 2.0, etc) we couldn't exactly make the API changes we've made in the past without bumping the .pc version here. Also using (for example) a tracker-sparql-0.10 pc file for version 0.16 would just be strange and confusing for people. We're currently talking about doing a 1.0 release for improved stability in another bug and given the project isn't in heavy development of new features, we could move to a tracker-{sparql|extract|...}-1.0.pc and make things easier for people. Patches welcomed :)
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > I am happy to make 0.17 a 1.0 release. Technically, I've always followed the > > > GLib/GTK+ release approach closely. > > > > Huh? They are not changing their .pc file version on every minor release, e.g > > gtk+-3.0. > > I never said exactly. > > About the .pc file, I don't feel strongly about how this is done or if we > change that and it's a minor detail. > > I agree it's a pain in the arse for some people Some people? Its pain in the arse for every (tracer-sparql using) app developer out there. > but since we've never had a > major release (e.g. 1.0, 2.0, etc) we couldn't exactly make the API changes > we've made in the past without bumping the .pc version here. Sure, where there *is* incompatible changes, it makes perfect sense to change .so and .pc versions but it hasn't been the case for a while now. > Also using (for > example) a tracker-sparql-0.10 pc file for version 0.16 would just be strange > and confusing for people. > > We're currently talking about doing a 1.0 release for improved stability in > another bug and given the project isn't in heavy development of new features, > we could move to a tracker-{sparql|extract|...}-1.0.pc and make things easier > for people. Indeed you can.