KDE4 related comments in 3.5 branch
kevin.krammer at gmx.at
Fri Oct 7 11:10:53 BST 2005
On Friday 07 October 2005 09:40, Stephan Kulow wrote:
> Am Freitag, 7. Oktober 2005 09:26 schrieb Martijn Klingens:
> > On Thursday 06 October 2005 22:57, Kevin Krammer wrote:
> > > On Thursday 06 October 2005 22:47, David Faure wrote:
> > > > It has all been branched away from KDE4, so it's fine to remove such
> > > > comments from the 3.5 branch IMHO, whenever they make trouble.
> > >
> > > Yeah, that's what I thought as well, but I didn't want to decided that
> > > all by myself :)
> > 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.
> And then? What would the KDE 3.5 programmer do with that information?
> Not that we would know the KDE4 API by now - but still even if we did:
> question A.
I think the idea is to reduce the incompatabilities between the application
and a possible KDE4.0 version of it, thus requiring less porting.
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.
So I will just remove KDE4 or BIC change related comments if necessary to add
Btw, would you like me to CCMAIL kde-core-devel on commits to kdelibs or is it
sufficient to add the DOX: markup?
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel