Qt 3.2 requirement

[Guillaume Laurent]

On Tuesday 29 July 2003 20:34, Marc Mutz wrote:
> On Tuesday 29 July 2003 18:17, Guillaume Laurent wrote:
>
> > "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...

Actually what you learn from failing projects is to be pragmatic and not give 
into nice theories.

> 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?)

No, because developers do not respond well to pressure. Especially pressure 
from their development environment. They are lazy, have limited time, and 
make mistakes. Either you make their environment easier to deal with, or 
they'll go their own way to make it easy.

We've been facing this problem with Rosegarden almost from the beginning of 
the KDE rewrite, with almost each of the different versions of Qt and KDE. 
The bottom line : we write for the smallest common denominator of the 
platforms we choose to support. In some cases when a feature is available in 
the newer platform but not the other, we simply disable the feature for the 
older platform. It's not a walk in the park, we lose a lot of our very 
limited time to this, and it introduced quite a few bugs. We do it for one 
reason only : our users. Not everyone has KDE 3.1 installed, KDE 3.0 is still 
in use.

Rosegarden is roughly 150KLOCs. Scale that to KDE, you'll get a lot of 
frustration, a lot of bugs, a lot of gory hacks which will linger on and then 
come back to bite us in the ass. And by the time you're done, you'll discover 
you did that in vain because nobody's using the old version of Qt anymore.

> 2. a stable framework for app developers to work with (esp. commercial
>    projects that KDE wants to be so attractive for)

Quite the opposite. You'll get a buggier environment which will take longer to 
be built.

> 3. more testers for HEAD apps since thay can check out bleeding-edge
>    apps on a stable desktop.

Reporting more bugs due to the multiple libs support.

> 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, you couldn't be more wrong. I've been confronted to this situation many 
times, both on my personal projects and at work. The *only* good reason to 
support several versions of a library is because your users require it. 
Otherwise you don't, because there's nothing but trouble there.

Software development is not about nice layering and perfect design on sound 
principles, it's about damage control. It's about making useful code with 
limited ressources. Layering and design, are merely tools to help you achieve 
this. They are not the goal.


-- 
						Guillaume.
						http://www.telegraph-road.org