future versions (Re: [kde-announce] Announcing KDE 3.2)

[Benjamin Meyer]

-----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-----