KDE4 related comments in 3.5 branch
Adriaan de Groot
groot at kde.org
Fri Oct 7 11:38:37 BST 2005
On Friday 07 October 2005 12:10, Kevin Krammer wrote:
> On Friday 07 October 2005 09:40, Stephan Kulow wrote:
> > Am Freitag, 7. Oktober 2005 09:26 schrieb Martijn Klingens:
> > > What would really rock is if the KDE 3.5 API docs were forward-looking
> > > and mention the new API that is in trunk (with a 'subject to change'
> > > disclaimer), i.e. "in KDE 4 this method will be replaced by
> > > KFoo::bar()". If EBN allows it with a hyperlink from 3.5 apidox to 4.0
> > > apidox.
I don't think that we should clutter the apidox with too much porting
information -- that can go in the porting guide if and when it comes out.
(And no, cross-linking from one dox branch to another is not straightforward,
though you can probably use full URLs in links -- fragile though).
> I think the idea is to reduce the incompatabilities between the application
> and a possible KDE4.0 version of it, thus requiring less porting.
This very much depends on the stuff upstream. In an ideal world, commits to
trunk which change the API would _also_ add dox to 3.5 or to the porting
guide explaining how to cope with the change. In this world, I expect this to
not happen at all, so that porting to the KDE4 API is a total disaster.
> That's why I orginally asked about adding @deprecated.
> However I no longer think this is a good idea. The method in question is
> not deprecated and even its other variant might not be present in KDE4,
> heck not even the class it is in.
We can add another tag if we like: @porting for instance.
These are your friends - Adem
GPG: FEA2 A3FE Adriaan de Groot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the kde-core-devel