1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
Status of planned changes and additions to the Telepathy API.
## 6.0
The full initial proposal is here: [[http://lists.freedesktop.org/archives/telepathy/2011-May/005525.html|http://lists.freedesktop.org/archives/telepathy/2011-May/005525.html]]
Summary: Actually, I'm not going to try summarising. Please read the proposal above before continuing.
telepathy-core version number is higher than the version number of everything in it, and MC is currently on version 5.x.
Steps to get there:
* 5.91 -- release everything as one module as-is.
* <wjt> i broadly think that being able to release the components as they currently stand all at once is a good step 1
* Drive tp-qt4's CMake-based build system from autotools.
* thing to watch out for: support for being recursed into and doing all the things automake wants to do recursively, either in- or out-of-tree ([[https://bugs.freedesktop.org/show_bug.cgi?id=32299|https://bugs.freedesktop.org/show_bug.cgi?id=32299]] --smcv's spec as submodule work)
* Use git-subtree and lots of git-merge to keep everything up to date.
* Directory structure would look like (courtesy of smcv, but not including the CMs):
[[!format txt """
${top_srcdir}
\- configure.ac (top level)
\- doc/
\- glib/
\- qt4/
\- examples/
\- glib/
\- qt4/
\- mission-control/
\- mission-control-plugins/
\- m4/
\- spec/
\- Account.xml (etc.)
\- telepathy-farstream/
\- telepathy-glib/
\- TelepathyQt4/
\- Farstream/
\- tests/
\- lib
\- glib
\- qt4
\- mc
\- account-manager
\- dispatcher
\- tools/
"""]]
* 5.93 -- deprecate fragile API/ABI
* Kill off telepathy-glib/svc-* and move them to telepathy-glib-dbus-vX (? see Open Questions below)
* The equivalent change in tp-qt4
* I'm not sure proxy.h goes to tp-glib-dbus-vX, because that API needs to be exposed by tp-glib high-level. that would mean tp-glib-dbus ABI breakage would break tp-glib too, no? -- Xavier Claessens
* Good point (my memory of what is generated and what isn't is unreliable) Fixed. -- alsuren
* Kill telepathy-glib/tp-cli-* too -- Xavier Claessens
* Kill off telepathy-core/telepathy-python/src/client.
* Kill off fully-qualified property names used in channel requests
* ensureTextChannel()-style methods on accounts and contacts -- (wjt [[http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html|http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html]])
* Since we are breaking tp-glib API/ABI, consider removing its deprecated APIs and some guarantees:
* tp_account_prepare_async, tp_account_manager_prepare_async are replaced by tp_proxy_prepare_async, I would like those APIs to be modified so preparing AM takes features of account, connection and contacts (See [[https://bugs.freedesktop.org/show_bug.cgi?id=26205#c19|https://bugs.freedesktop.org/show_bug.cgi?id=26205#c19]])
* Stop [[TpContact|TpContact]] from taking a strong ref on its [[TpConnection|TpConnection]] (See [[https://bugs.freedesktop.org/show_bug.cgi?id=26205#c26|https://bugs.freedesktop.org/show_bug.cgi?id=26205#c26]])
* Stop emitting "invalidated" signal from [[TpProxy|TpProxy]]'s dispose
* 5.97 -- test API/ABI breakage mechanisms
* Rename the spec namespaces to vX and ensure that the mechanisms for demanding a restart on spec version mismatches work (make no other spec changes here)
* 6.0 -- telepathy-not-1.0
* Copy-paste code into one big git tree (no submodules going forward: they're far too much of a pain in the ass to work with. Don't make any attempt to preserve history: just refer everyone to the commit id of each submodule that was imported)
* rename the spec namespace to vY just for fun.
* 6.x -- things that would be nice to happen, but shouldn't block 6.0 from happening (?)
* GDbus rewrite of tp-glib
* Rename the spec namespace again, and delete *all* of the deprecated spec stuff.
* 7.0 -- Things that would be nice to do API but may not actually happen
* Kill off [[TpHandle|TpHandle]]? -- (wjt [[http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html|http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html]])
Open Questions
* How long do we use submodules for, or do we force everyone to port all of their changes to telepathy-core by hand, from the first day of the project?
* What do we do with the media streaming stuff? Does tpfs get included in tp-core?
* I'm not quite sure how the mechanism for breaking the tp-glib-dbus apis are supposed to work. Here are a few proposals:
* Make each CM author #include <telepathy-glib-dbus-vX/svc-channel.h>, and sed *all of their source code* to update from version X to version Y.
* Same as above, but if the channel interface hasn't changed between vX and vY, generate <telepathy-glib-dbus-vX/svc-channel.h> which #includes <telepathy-glib-dbus-vY/svc-channel.h>. This would avoid too many bullshit sed commits for unchanged files, and encourage users to actually check what's changed on a per-file basis rather than blindly sedding and hoping for the best.
* Let CM authors #include <telepathy-glib-dbus/svc-channel.h> as long as they have defined the macro TP_DBUS_VERSION=X. This would let CM writers simply check their code for compat by hand and bump the version number to assert that it's all correct.
* Same as the above, but (e.g.) #define tp_svc_channel_interface_* so that each function only produces a compiler warning if its semantics has been broken between version X and version Y and it is *actually used* (more fine-grained than the header approach).
Things that I (alsuren) don't think will ever happen:
* Killing off the enums (xclassens [[http://lists.freedesktop.org/archives/telepathy/2011-June/005540.html|http://lists.freedesktop.org/archives/telepathy/2011-June/005540.html]]).
* We either need to expose enums or strings for things like connection status. I have a bug (alsuren [[https://bugs.freedesktop.org/show_bug.cgi?id=37803|https://bugs.freedesktop.org/show_bug.cgi?id=37803]]) to use GEnum to link the enums and strings more conveniently.
|
