Qt 3.2 requirement

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 July 2003 12:34, Marc Mutz wrote:
> Now, I'm waiting for a substantiated rebuttal of the pro-arguments. I
> don't expect them to be forthcoming. Common sense is on the pro side.
> Substantial arguments are on the pro side. Sorry, but religious
> fighting for the status quo is all I see from the contra side.

to play devil's advocate[1], the flip side to the coin is that maintaining 
multiple versions of Qt means:

 o having to work around bugs / misfeatures that are already fixed in Qt 3.2
 o having to keep multiple versions of Qt around for testing.
 o having to maintain multiple code paths which you may or may not be able to 
test thoroughly.

all of the above leads to:

 o longer development time
 o more obfuscated code thanks to ugly #ifdef'ery
 o hightens the chance for bugs in code left there for backwards compat but 
which few (if any, in some cases) of the developers use
 o bugs in the code that appear when run with one version of Qt but not 
another (the recent konq sidebar commit that relied on Qt 3.2 was a good 
example of that)
 o less people testing what will be the common version of Qt+KDE when KDE 3.2 
arrives.

there are costs both ways. trying to enforce better layering by making more 
work rather than encouraging and enforcing good coding practice is a bit like 
leaving your shoelaces untied so you can learn how to break a fall better.

i also think there is a distinction between applications and the base 
libraries. while the application developers may wish to develop against KDE 
3.1, it hardly makes sense for kdelibs 3.2 to develop against kdelibs 3.1... 
same for Qt reliance.

perhaps there needs to be a distinction between libraries (kdelibs and perhaps 
kdebase) and applications and application-level libraries (everything else) 
when it comes to Qt dependencies, which is actually a natural extension of 
your arguments regarding layering.

i also look at past releases of KDE, from the time that i was a spectator to 
now as someone who is somewhat involved in things, and i don't see the policy 
to date causing egregious problems for people. i see no problem with people 
such as yourself keeping compat to earlier versions of KDE libraries in your 
applications, in fact i think that's a fine thing when and where possible! 
but that doesn't mean that people should need to make their _development 
code_ uglier and spend more time coding and testing against multiple versions 
of Qt and KDE libs. there are time, (hard drive) space and reasonability 
issues that conflict with that concept being mandated on all developers.

even more poignantly, the Qt 3.2 vs Qt 3.1 issue is not an issue for end 
users, since they will upgrade their Qt along with the KDE packages as is 
generally the case with binary packages. so for KDE 3.2 proper this isn't an 
issue, it's really only an issue for applications that will be a part of 3.2 
that wish to do independant release between now and then and for developers 
who couldn't be bothered to compile 3.2 themselves.

third party developers will continue to maintain compatibility as necessary 
against multiple version as they see fit. the only thing KDE can do to alter 
that is to make the process easier or even unnecessary. we do the former by 
maintaining BC and the latter by the natural maturation of the libraries.

i'm glad you're very convinced of your position in this matter, but common 
sense and truly rigorous evaluation shows that there are benefits and 
challenges to both positions.

[1] i'm not horrendously concerned either way myself. i lean personally to 
using Qt 3.2 for HEAD now, but if that doesn't happen so be it.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/Jsiy1rcusafx20MRAmfYAJ424uqcesNbWY2VKrPwpiPwjb8I8ACfSVKT
CK1MJ5zHUs0N/TBwazH60zM=
=2fRm
-----END PGP SIGNATURE-----