Qt 3.2 requirement

[Marc Mutz]

On Tuesday 29 July 2003 18:17, Guillaume Laurent wrote:
<snip>
> "decent layering" is a nice theory.

It's not a theory. It's practice whenever you have a library. Whether or 
not you use that layering to your advantage or work against it by 
relying on looking at the source instead of at the documented interface 
is up to you. I'm saying that supporting two Qt versions in parallel 
forces us more into adhering to the layering.

> "Fixing the source of the problem 
> 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? 
B/c 50% of all software project fail, we are not allowed to learn from 
that fact? Tztztz...

Let's review the facts:

Supporting more than one version of a library (be it Qt or kdelibs) 
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 
significantly speeding up app development, leading to the possibility 
of having apps that have additional releases between the KDE ones, with 
fewer additional changes per release, but more frequent ones, so you 
get more testing done.

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.

Marc

-- 
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
-------------- 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/20030729/32915fe4/attachment.sig>