Moving 3.5 development into branches/KDE/3.5
mo85 at cornell.edu
Tue May 31 14:41:48 BST 2005
> I believe that is the best solution so far. Adding my own thoughts:
> - now: a relaxed feature and message freeze for is announced
> - now + 2 weeks: trunk/KDE/kdelibs branches off to branches/KDE/3.5 and
> KDE4 takes over
> - kdelibs 3.5 gets bugfixes and maybe even some features --- if backported
> from KDE4
I am not sure I view this as a better strategy, but IMHO, whatever
happens, the following constraints should be encouraged to be kept to by
1) No new use of the old-style socket classes.
2) No new use of QPtrList, and in general, of setAutoDelete
3) No new use of raster ops.
4) No new code painting on widgets outside paint events
Anyone think of anything else that's a pain to port?
More information about the kde-core-devel