Qt 3.2 requirement

[Marc Mutz]

Hi!

Prologue:

KDE has a nice track-record of doing things "because they were always 
done this way". This is again one of those issues where this shows up.

KDE - it is said - is all about pragmatism. However, recently it's more 
about religiously fighting for principles even when they start hurting 
the project. This thread is one example. The STL debate was another 
one, and I expect the no-GPL-in-kdelibs to be forthcoming.

On Friday 25 July 2003 23:56, Martijn Klingens wrote:
> On Friday 25 July 2003 19:47, Ralf Nolden wrote:
> > I ack coolo that supporting two versions is a pain.
<snip>
> Since Kopete has standalone releases that have to compile against
> other KDE/Qt versions I can confirm from personal experience that
> maintaining compatibility across multiple versions is a pain if you
> also want to use the newest stuff where it's available (or are used
> to it and forget it wasn't in the old version).

This pain is self-made. It stems from violating the layering
  Qt<-KDElibs<-apps

Qt/kdelibs layering is e.g. violated where (as Matthias detailed) 
kdelibs subclasses try to fix bugs in Qt instead of fixing Qt in the 
first place or maintaining a layer between Qt and kdelibs (the famous 
qt-addons) that is bound to a specific Qt version.

Similarly, apps/kdelibs layering is violated where e.g. apps try to work 
around bugs in kdelibs or Qt w/o #ifdef'ing the workaround to a 
particular Qt/kdelibs version. The latter would force a re-evaluation 
of the workaround for every new release, guaranteeing that workarounds 
drop out of the code as their causes are fixed upstream. As it is now, 
however, KMail (as an example) is full of workarounds for bugs or 
missing functionality in Qt/kdelibs that no-one understands anymore. I 
don't expect other subprojects to be much better in this regard.

Layering would automatically be maintained more accurately if KDE 
adopted the policy of only requiring the latest stable release 
branch's .0 version. Bug fixing in the libs is great, but using this as 
an argument for requiring the new libs is nonsense. If people are being 
bitten by bugs that are fixed in an upstream release, then they have 
incentive enough to update. OTOH, people who don't experience those 
bugs won't want to update, b/c - like it or not - updates are always a 
risk for a production system.

> For Kopete it's something we'll have to live with, but for KDE in
> general I'd strongly recommend AGAINST maintaining 3.1 compatibility.
<snip>

You should ask yourself what that pain consists of. I strongly suspect 
that it's inter-version differences of the upstream libs. If that is 
so, KDE - lacking serious regression testing - very much benefits from 
apps like KOffice or Kopete that want to maintain compat with at least 
the last stable Qt/KDE release. It's frequently such projects that 
point out incompatible (be it BIC or behavioural) changes in kdelibs/
Qt, whereas the rest just accepts them with a recompile and a fix.

> I encourage anyone who disagrees to try maintaining compat for a
> fairly big application for a few months and then tell about the
> experiences. I'm pretty confident all of you would instantly agree
> with Coolo and Ralf by then! :)

The most important pain you have with keeping backwards compat for a 
subproject is that people try to bash you for doing so and don't have 
anything better to do than implement a new feature in kdelibs and run 
around all of CVS porting apps to use that new feature - without 
#ifdefs.

The std argument of course being "I'm too lazy to test my stuff and want 
others to perform this painful task for me". Of course, they don't say 
so. But look around this thread. All you'll see as arguments for 
requiring Qt 3.2 for CVS HEAD is paraphrased and euphemism-ized "I 
don't want to write tests for my new feature. I want others to play the 
guinea pig", sometimes paired with "I don't want to backport my bug 
fixes. I consider KDE 3.2 a bugfix release. Who on earth still uses KDE 
3.1.x?".

I'm sorry if the above sounds harsh, but it's the essence of the KDE 
development model if you look at it from outside it's ivory tower.

The running after people commiting dependencies on later libs in your 
code without asking for permission is the real pain you have when you 
maintain a project for two different KDE versions. The issues you get 
when upgrading to a new Qt or kdelibs version are for the vast amount 
of cases self-made: You've relied on undocumented or not properly 
documented behaviour (ie. you looked at the source instead of at the 
docs). That is fixed with a quick patch and then done, whereas the 
introduction of dependencies is a permanently recurring problem.

Which brings us back to the violation of layering. Every software 
professional will tell you how very important it is to have a decent 
layering in your code. Without proper layering, you can't regression-
test each layer independently and are thus fallible to all those tiny 
little buglets that haunt KDE for every new Qt release.

Instead of fixing the symptoms, KDE should fix the _cause_.

Another point that's missing from the discussion up to now, BTW:
Don't you think Kopete and KOffice get *more* testers b/c they run on a 
stable KDE platform instead of requiring users to upgrade all of the 
metaphorical dog with the tail? Why else would you want to maintain 
backwards compat?

Marc

-- 
It's one thing to accept a risk to your own data, but quite another to
standardize on something that imposes that risk on others, no matter
how unlikely you think it is that anything "really bad" will happen,
and no matter how desirable the outcome.  -- Bart Schaefer, on ietf-822
-------------- 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/20030728/a1b270c4/attachment.sig>