Qt 3.2 requirement

Brad Hards bhards at bigpond.net.au
Mon Jul 28 11:23:24 BST 2003

Hash: SHA1

On Mon, 28 Jul 2003 19:49 pm, Chris Howells wrote:
> Hi,
> On Monday 28 July 2003 10:46, Bernhard Reiter wrote:
> > Naturally some people want to play with new stuff, that is perfectly
> > fine. Others want to keep stuff stable, that's also a worthwhile  goal.
> We're talking about CVS HEAD here. HEAD is not stable. That's the point.
I agree with both these points, but I'd like to expand on them.

I'm a user (not a KDE developer). I want to run the latest stuff on one of my 
machines. I build from CVS HEAD, update often, and expect a few problems. 
Sometimes I can even figure them out on my own.

I also have a machine that is a bit more restrained. Typically, it has the 
last stable release on it. Sometimes just vendor RPMs of KDE.

The way things are right now, I'd be unhappy to have problems on the stable 
machine. I also would want to miss out on latest bits of KOffice and Kmail 
(plus Konqi, yenc support for KNode, and lots more great features) on the 
main box. I think a stable Qt is the only sensible choice for KDE 3.1 

But if you ever want KDE 3.2 to stabilise, you need to decide on the 
dependencies, and test the whole lot together for as long as possible. 
Especially big/critical/changing ones, like the parsers and especially Qt. If 
the next version of KDE is going to depend on a particular version of Qt, 
then try to do most of the development work with that version. Late changes 
in configuration only ever causes grief.


BTW: I also note the symbiotic relationship between TT and KDE. In my opinion, 
users and developers owe TT a reasonable amount of testing in exchange for 
the early releases and  ongoing support.
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list