Qt 3.2 requirement

[Ralf Nolden]

On Freitag, 25. Juli 2003 14:32, Bernhard Reiter wrote:
> On Friday 25 July 2003 13:16, Stephan Kulow wrote:
> > On Friday 25 July 2003 12:24, Bernhard Reiter wrote:
> > > On Wednesday 23 July 2003 21:31, Cornelius Schumacher wrote:
> > > > I would prefer, if we could keep compatibility with Qt 3.1 for as
> > > > long as possible, at least until it is part of the major
> > > > distributions. Requiring a developer to compile a new Qt in order to
> > > > be able to test a patch for any KDE application in the KDE CVS is, in
> > > > my opinion, too much. This will prevent some people from contributing
> > > > to KDE and that's clearly not what we want.
> > >
> > > I second that.
> >
> > I see this as very weak argument. Compiling kdelibs takes longer than Qt
> > and while kdelibs changes daily (possibly incompatible), we talk about a
> > one time Qt compilation.
> > If Qt 3.2 is released and has less bugs than Qt 3.1.x, we should require
> > it as supporting two is a nightmare.
>
> It is a question going beyond the pure compile time.
>
> In my experience your argument leads a huge block
> consisting of QT /kdelibs /application that is changed altogether,
> leading to a lower quality of the overall system, because the resistance
> to make incompatible changes to the underlying libaries is lowered.
> Qt 3.2 is not a bug-fix only release, it has incompatible changes.
> In my experience changing to it will make the situation more unstable.
> You could see it as testing QT 3.2 with KDE.
> Weaknesses or bugs in QT 3.1.2 at least are stable.
>
> When trying to fix bugs in currently used KDE versions,
> I've frequently been pointed to try the "latest" and "greatest"
> version from CVS on the whole block because that was what
> developers are using. It lead to problems which were not present
> before and I did not get to the point in actually fixing the application
> bug. It is not a weak argument, because stablising KDE application code
> towards a certainly level is getting very cost intensive.

If you use qt-copy that's your fault :-) You should take the official release 
version from Trolltech and the beta versions of that version have been tested 
with KDE plus the results folded back into Qt. You won't and can't prevent 
developers to use the newest library and so over time the whole thing becomes 
a restriction to say we only use qt-3.1.x because qt-3.2 may have the classes 
you want to use. Also, for those who want to test indian languages they 
*need* to take Qt 3.2. It *will* be a requirement. The more it is tested, the 
better, because within the timeframe of the KDE 3.2 release a bugfix release 
of Qt 3.2 will be available for sure, so we can have KDE 3.2 use a *stable* 
and *well-tested* Qt 3.2.x

I ack coolo that supporting two versions is a pain. Hence my question where a 
KDE 3.1.x environment has problems with Qt 3.2 so people wanting to use Qt 
3.2 can given an exact answer where to expect problems if they want to use 
KDE 3.1 with it.

Ralf

-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030725/fe7a5673/attachment.sig>