[Telepathy] choosing Telepathy versions for GNOME 3.12

[Xavier Claessens]

Le mercredi 19 mars 2014 à 13:37 +0000, Simon McVittie a écrit :
> When we have consensus, we should contact distributor-list at gnome.org as
> well as this list, like Guillaume did last time.

I would advice to stay conservative this cycle and use the same branch
than for GNOME 3.10. We (upstream) should make sure to backport
important fixes into latest stable branches though.

> The tl;dr version is that I'm proposing:
> 
> telepathy-glib: new 0.24.x

> telepathy-idle: keep 0.2.x, or new 0.3.x? (see below)
> telepathy-logger: keep 0.8.x, or new 0.10.x? (see below)
> 
> telepathy-mission-control: keep 5.16.x
> telepathy-gabble: keep 0.18.x
> telepathy-salut: keep 0.8.x
> telepathy-rakia: keep 0.8.x
> telepathy-haze: keep 0.8.x
> telepathy-farstream: keep 0.6.x

Any particular reason to bump telepathy-glib to 0.24.x if distro keeps
CMs requiring only 0.22 ? Maybe Empathy 3.12 already depends on 0.24 ?

Note that currently Ubuntu 14.04 LTS is shipping Empathy 3.8 and
telepathy-glib 0.22. So if we have strong reasons to upgrade to newer
version we should convince Ubuntu ASAP, otherwise I would suggest other
distros to align. I really think it is important for everyone if major
distros align on the same stable branches, that gives a signal to
upstream that we should give special care at backporting important stuff
into specific versions.

> The future
> ==========
> 
> I would like to have Telepathy 1.0 stable well before GNOME 3.14
> freezes; that hopefully means these will be the last round of Telepathy
> 0.x stable releases (although we might do a telepathy-glib 0.26 or
> telepathy-mission-control 5.18 if necessary).

+1 for targeting tp1.0 for GNOME 3.14, but if for any reason we can't
make it happen early in the cycle, we should postpone.

> The major things left to do are:
> 
> * merge my port to GDBus, or decide not to

It's not strictly release blocker, but since the code is already there,
it works, and I already reviewed part of it, it would be sad to not have
it.

> * implement MC 5 account import in MC 6

That's release blocker for sure.

> * make TpClientFactory the top-level object?

I'm not considering this release blocker, but still nice to have. I
personally won't implement it, but I think Guillaume is doing it. So his
call.

> * start tracking the ABI properly

Yes, release blocker.

> I don't think the Names and redesigned Avatars interfaces should be
> blockers for 1.0.

They are not release blocker, and still have open questions IIRC. So it
would be of course nice to have, but I think it won't make it. Also
allowing for future dbus iface breaks is actually the whole point of
tp1.0 interface versioning.

Regards,
Xavier Claessens.