[Telepathy] Announce: telepathy-spec 0.99.1

[Simon McVittie]

On 20/09/13 00:12, David Edmundson wrote:
> Do you have a rough timescale on this? i.e a 2 weeks or 6 months? Longer?

Closer to "months". We're hoping to have Telepathy 1 working well enough
to be the recommended version by the time GNOME 3.12 freezes, which is
in less than 6 months. Hard to say exactly, though - we've never done
this before! Once we have a working 'next' (Telepathy 1) branch for each
of our projects, we can look at how long it's taken so far and how much
is still to do. Exact cutoff points for the "merge now or wait" decision
can be negotiated, if it would benefit KDE or other Telepathy-Qt
consumers (e.g. if there's a KDE release soon before a GNOME release, it
would make sense to use the KDE freeze as the go/no-go boundary, and
vice versa).

We're doing a round of "Telepathy 0" stable-branch releases about now
(so that distros with GNOME 3.10 don't release with some random snapshot
that's hard to support), and I intend to do at least one more round of
"Telepathy 0" stable releases, with the same policies (i.e. "no new
features; no intrusive changes; bugs get fixed if feasible").

This has been vaguely planned since 2009 and it's long past time we made
it actually happen :-) (see various past mailing list threads about
Telepathy 1.0, most of which stalled because not enough people were
available to do the work). We've had backwards compatibility since about
2005-2006 and it's really slowed development - whenever we add a new way
to do things, there's so much extra effort involved in keeping the old
way working too that we end up not doing the new way at all. That's OK
up to a point, but it isn't sustainable.

If nothing else, we're using "Telepathy 1" as an incentive to bring the
Telepathy 0 branches of Mission Control and the major CMs up-to-date,
which benefits the "Telepathy 0" world too.

> How will this work with regards to compatibility?

It's a "flag day" upgrade, I'm afraid: the intention is that
distributions/projects choose a point in their development cycle at
which they'll cut over to Telepathy 1 (i.e. merge the branches of
Empathy, GNOME Shell, KDE-Telepathy etc. that do so).

The "Telepathy 0" and "Telepathy 1" worlds are distinct - for
developers, the idea is that a different major version of Mission
Control will manage a parallel set of accounts. CMs are not actually
parallel-installable yet, but I intend to make that change before we
release the first Telepathy 1 snapshot of Mission Control.

We haven't really worked out how the upgrade story for users works; when
Telepathy 1 approaches stable, the upgrade story will probably involve
Mission Control 6 (Telepathy 1) migrating all your Mission Control 5
(Telepathy 0) accounts the first time it's run.

The way I'd suggest dealing with it in Telepathy-Qt is to follow what
we're doing in GLib-land:

1. get master building against telepathy-glib with all
   its deprecation warnings turned on (may involve re-copying
   test/example CMs from telepathy-glib master)

2. start a 'next' branch in each project, in which the
   D-Bus API breaks; don't guarantee API stability for it,
   at least short-term

3. port things to 'next'

4. this is also a good time to make any C++ API breaks you've been
   wanting to make; update library, release library, update
   library-users, repeat

... somewhat later, when the 'next' versions of Mission Control, Logger,
all CMs, etc. all work well...

5. merge all the 'next' branches into 'master' and release as 1.0

Don't worry, we won't do step 5 without quite a lot of pre-announcement!

    S