Future of KDE Development

[Friedrich W. H. Kossebau]

Am Montag, 14. Februar 2005 20:50, schrieb Alexander Neundorf:
> On Monday 14 February 2005 20:27, Torsten Rahn wrote:
> ...
>
> > Apart from that I support Stephans suggestion to have a KDE 3.5 release
> > so that all docwriters, usability-engineers, designers, translators, etc.
> > will keep working and won't loose interest in the KDE project because
> > they have to idle around.
> > And of course this would give us more time for the developers to work on
> > KDE 4.0: While preparing a 3.5 release might take about 4-5 months
> > programmers can use this time to work on porting kdelibs/base and
> > cleaning up the API already. Once this would be done and KDE 3.5 is
> > released there would be additional 8-9 months left to port applications,
> > do bugfixing etc. So in total KDE 4.0 work would cover about 13-14 months
> > which wouldn't be noted by the public at all. If we would work for 14
> > months w/o releasing any further software in the meantime then this would
> > at least create bad PR for our project and hurt our project severely.
> >
> > That's why I vote for a KDE 3.5 release.
>
> This sounds very reasonable.

I think so, too.

> To keep problems to a minimum, kdelibs should stay frozen except for
> bugfixes, 

I would not like that (having an working extension on my disk which gives all 
users their face in a lot of places, e.g. file properties dialog, not only 
kdm). There are some places in kdelibs which I suppose need to evolve also a 
little for 3.5 (kmdi, khtml, kate interfaces, etc.)

> so app developers will never have to update kdelibs to keep their 
> apps working. 

Those, who do not like to use the latest features of kdelibs, (almost) never 
had to update kdelibs.

Regards
Friedrich

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050214/93449d89/attachment.sig>