KDE4 release discussion, Was: KIO::NetAccess static methods question

[Alexander Neundorf]

Hi,

On Thursday 25 October 2007, Aaron J. Seigo wrote:
> On Wednesday 24 October 2007, Andreas Pakulat wrote:
> > Anyway, time will tell wether plasma will be the only kde4.0 library
> > thats going to break BC for 4.1 or not and wether that will mean KDE 5.0
> > is released a year after 4.0 or not.
>
> just to make it very clear: libplasma is in kdebase/workspace (not kdelibs;
> not even kdebase/runtime), is replacing a library that *never* maintained
> BC (libkicker; heck, it didn't even install its headers so people would
> just statically link it in to applets ... i'm not joking) and is being
> rather forced into this situation with the advent of widgets/layouts for
> QGV only coming with 4.4 ...

Considering that plasma is the default desktop of KDE 4.0 and many/some/few 
people will see some performance issues with plasma with Qt 4.3 and as such 
this may make whole KDE4 feel slow (I know, it's "just" plasma which is very 
new etc.) and also considering that there will be significant improvements to 
the printing support in Qt 4.4, and given that Qt 4.4 will be released Q1 
2008 (and KDE 4 too) and will apparently be the recommended version to use 
for KDE 4 (because otherwise plasma and printing are not that cool), and also 
considering that if Qt 4.4 will be recommended it should be tested well, how 
about requiring Qt 4.4 for the KDE 4 release (libs + base + workspace) ?

(I know we are right now releasing RC1 of the KDK (KDE Development Kit) and 
changing the required version of Qt some months later is not what one would 
expect at that point)

> btw, i too am all for this position: "we can make new API modules, on a
> case by case basis, 'private' and ship with a clear notice that BC is not
> being enforced yet; but our existing APIs (kdecore, kdeui, kio..) must
> remain BC"
>
> iow, i think i pretty much agree with you. 

/me too.

Alex

P.S. I'm not subscribed to the release mailing list, I guess many other 
developers aren't either, but actually I think the release date/feature 
set/etc. discussions should happen on k-c-d so the core developers 
(kde-core-devel as opposed to kde-devel) don't feel left out (because they 
don't consider themselves release managers). I expected the release mailing 
list would be basically for release-technical/formal discussions, not for 
deciding about release dates