-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm not in favor of too much revamping for KDE 4.0 because that tends to > give application developers only more work to do without getting much in > return. It will take longer for development books to catch up, etc. etc. > Having to make changes for Qt4 sounds already bad enough. > > Cheers, > Waldo I don't know about this. A major release is the only time that you can break binary compatibility. Cleaning out classes that are no longer needed (replaced by better Qt classes), removing depreciated functions, refactoring a class so that it is ten times better, and removing headers that aren't needed. Although the user will only notice little things here and there it is needed for the long term maintenance of a code base. This is actually something that should be practiced now. Building the libs without compatibility and then fixing what breaks. 3.3 will have compatibility turn on. This will encourage developers to being thinking about what they had wanted to rework/fix/cleanup now rather then in a hasty two months before release. The in the libs currently I believe there is a number of different ways (comments, @depreciated, @remove in 4, function descriptions saying to fix for 4 or use a different function) that developers have marked a function to be depreciated. Maybe determining a standard ifdef would be a good idea. I know that in Qt there is also a #warning stating to remember to remove the function in Qt4. If Qt4 is released and is stable in May then pushing straight to KDE 4.0 next winter I think would be a good idea, but if Qt4 is released as a beta in may and 4.0 is released in September then having kde3.3 in June would be a good idea and kde4.0 next spring. I for one would like seeing a faster turn around then 12 months. It seemed like when there is a release more work is done v.s. R&D. Also there seems to be enough new coming right around the corner to validate having a 3.3 in August. What about having a feature freeze in three months say May 9th? - -Benjamin Meyer P.S. Spell check in KMail rocks. - -- Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAIn6m1rZ3LTw38vIRAjOrAJ9e8koltZjeqNAnMZksvY9oL+wiGACgnvwa mqxIUvgrcWC5zQx5Wd7BeWU= =BM4M -----END PGP SIGNATURE-----