[Telepathy] Telepathy 1.0 will never happen

[Robert McQueen]

On Mon, 2011-05-30 at 12:08 -0700, Travis Reitter wrote:
> On Mon, 2011-05-30 at 18:17 +0100, Will Thompson wrote:
> > Thoughts?
> 
> I think the biggest question would be how this affects API and ABI
> stability guarantees (particularly for telepathy-glib and
> telepathy-qt4).

The higher-level (client) APIs would be maintained until we had a solid
reason to break them - normal shared library versioning/transitions
would take place as and when required (note that I think we don't do
this often enough - tp-glib is *not* a GNOME module, it's an external
dependency, so holding ourself to GNOME platform ABI guarantees is just
making a rod for our own back). The lower-level (autogen from D-Bus, and
service APIs from tp-glib) ABIs would break more often, most likely
whenever our D-Bus API version changed.

> Would we break API/ABI when moving components into the One Big Repo then
> continue as we have done (adding API as DRAFT, un-drafting, and
> deprecating old API)? Would we periodically flush out API that have been
> deprecated for X days/releases?

We wouldn't need draft spec API because potentially any Telepathy
release can change the D-Bus API version, so incompatible changes
(deletion, modifying arguments, etc) are A-OK. No more fear! We can just
focus on designing the minimal client API for your use-case, and merge
it - not designing the D-Bus API for current and all future use-cases
and being terrified about getting it wrong. Our entire D-Bus API won't
need to be full of a{sv} any more. It will be beautiful!

> Would we eventually aim for rotating stability guarantees?

Not sure what you mean - higher-level APIs would be more stable, and
lower-level ones would potentially break every release.

> My biggest sticking point with Telepathy has been how often "best
> practices" for implementing or using any given feature has shifted
> around. (I think this has gotten a bit better over time as the API have
> matured though). We've been good about deprecation in general, but it
> has, historically, been a bit of work to keep up with the
> recommended/actively-supported API.

This is because the D-Bus API has between 0 and 3 ways to do anything,
most commonly 2. In the new world, it would have 0 or 1 way to do
anything because we would just delete the old ways. There would be no
D-Bus API deprecation process - only deletion - it would be shared
library version business as usual in our high-level client APIs (Glib /
Qt4).

> How would this proposal change these nominal and actual API/ABI
> stabilities for CM and client developers relative to the standard
> "branch 1.0, cut deprecated API, declare stability/victory" strategy?

As I said elsewhere on the thread - CM authors are expected to keep up
with the pace of development - and we can deploy continuous integration
to help give us visibility on this. Even if the ABI breaks, some things
might just need a rebuild (unrelated deletions/changes), and if the API
has changed incompatible the relevant bits should stop building.

> Regards,
> -Travis

Regards,
Rob

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk