From kde-core-devel Tue Jul 29 19:19:14 2003 From: "Aaron J. Seigo" Date: Tue, 29 Jul 2003 19:19:14 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105951439414867 -----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-----