Qt 3.1b1

Matthias Ettrich ettrich at trolltech.com
Tue Sep 10 08:42:33 BST 2002

On Tuesday 10 September 2002 08:29, Allan Sandfeld Jensen wrote:
> >
> > It also means we can require Qt 3.1 for KDE 3.1, although I'm not exactly
> > sure what kind of advantages Qt3.1 brings over Qt3.0 (Is there a
> > changelog somewhere?)
> Why "require" it if we dont need it?

Despite the danger of sounding like an IKEA commercial:

- because it's an improvement of big parts KDE's API, remember, KDE is a 
application development framework
- because it comes with better documentation
- because it has a better GUI designer
- because it's faster 
- because it's better
- because it will work fine together with KDE 3.1
- because you can step by step get rid of workarounds in the code that are no 
longer needed.
- because it will not take long from developer updating to it to code that 
relies on some bugfix or improvement that's in 3.1
- because it contains many small things KDE developers asked for
- because the KDE developers at Trolltech see new versions as a part of their 
contribution to KDE
- because then the version numbers are in sync ;-)

> It is going to have more bugs than the welltestet 3.0.5-6 release to start
> with. Wouldnt it be better to support both even if this requires a few
> #ifdefs to take advantage of new 3.1 features?

Wouldn't it then be better to release the welltested KDE 3.0 release to start 
with?  Seriously, what the changes file does not tell you are litterally 
hundreds of bugfixes since 3.0.5, most having been reported by our commercial 
users and by KDE developers. Some are about speed, some are about memory 
consumption, some are about inconsistencies, some are plain crashes, some are 
simply wrong.

"welltested" means "bugs are well known", not "bugs are fixed". The 
"welltesting" of 3.0 results in fixes and improvements in 3.1.  We'll do a 
3.0.6 soon, which will fix some issues, but of course far less than what you 
can do in a major release.

You may not need the i18n improvements with your locale, but many other KDE 
users might. Shall they have to rely on an untested KDE on a non-supported 
works-by-chance Qt version?


More information about the kde-core-devel mailing list