KDE4 related comments in 3.5 branch

[Adriaan de Groot]

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
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051007/ee4c3b25/attachment.sig>