From kde-core-devel Tue Jul 29 18:34:53 2003 From: Marc Mutz Date: Tue, 29 Jul 2003 18:34:53 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105950416802146 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_O5rJ/7MllkxH5zf" --Boundary-02=_O5rJ/7MllkxH5zf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 29 July 2003 18:17, Guillaume Laurent wrote: > "decent layering" is a nice theory. It's not a theory. It's practice whenever you have a library. Whether or=20 not you use that layering to your advantage or work against it by=20 relying on looking at the source instead of at the documented interface=20 is up to you. I'm saying that supporting two Qt versions in parallel=20 forces us more into adhering to the layering. > "Fixing the source of the problem=20 > and not symptoms" is another. None withstand the test of reality. Do you really want to use these as an argument for a Qt 3.2 requirement?=20 B/c 50% of all software project fail, we are not allowed to learn from=20 that fact? Tztztz... Let's review the facts: Supporting more than one version of a library (be it Qt or kdelibs)=20 leads to 1. better layering of the code, since there is pressure to find code that works with both versions to reduce #ifdefs and enable switching to the later library version _without_ recompiling (what do we need BC for if we don't support this?) 2. a stable framework for app developers to work with (esp. commercial projects that KDE wants to be so attractive for) 3. more testers for HEAD apps since thay can check out bleeding-edge apps on a stable desktop. Whereas the only arguments against supporting multiple versions are 1. It's a pain (unspecified up to now) 2. Less testing with the later lib. My rebuttal of those arguments: ad 1: The pain is self-made and stems from (a) violating the layering and (b) people that don't respect the backwards compat policy. ad 2: That there is actually more testing done if everyone is forced to use the newer versions remains to be proven. As it is now, most problems of an upgrade are found within the first few days after update to the new version by the few early-adoptors that always bring up those fixes (kudos to those!). They will continue to be early-adoptors, even when no-one forces them to upgrade. OTOH, having a stable framework for app development has the potential of=20 significantly speeding up app development, leading to the possibility=20 of having apps that have additional releases between the KDE ones, with=20 fewer additional changes per release, but more frequent ones, so you=20 get more testing done. Now, I'm waiting for a substantiated rebuttal of the pro-arguments. I=20 don't expect them to be forthcoming. Common sense is on the pro side.=20 Substantial arguments are on the pro side. Sorry, but religious=20 fighting for the status quo is all I see from the contra side. Marc =2D-=20 There's a lot of "throwing the baby out with the bathwater" going on, but the bathwater is so foul that many companies don't mind the occasional loss of baby. -- Bruce Schneier on spam filters, Crypto-Gram 07/2003 --Boundary-02=_O5rJ/7MllkxH5zf Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/Jr5O3oWD+L2/6DgRAr38AKCimXaGsrXA68cUz6om2/tujln4KgCeIFzG s1bbFkm2bq3giEIu7xg9VKk= =oFbL -----END PGP SIGNATURE----- --Boundary-02=_O5rJ/7MllkxH5zf--