From kde-core-devel Tue Jul 29 20:28:17 2003 From: Marc Mutz Date: Tue, 29 Jul 2003 20:28:17 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105951111210532 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_CktJ/5WqW/o8d4w" --Boundary-02=_CktJ/5WqW/o8d4w Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 29 July 2003 21:16, Lubos Lunak wrote: > On Tuesday 29 of July 2003 20:34, Marc Mutz wrote: > > 1. better layering of the code, > This can be achieved even without supporting multiple versions, How? > > 2. a stable framework for app developers to work with (esp. > > commercial projects that KDE wants to be so attractive for) > > If you're suggesting Qt-3.1 is still good enough for KDE, Where did I say so? What I said is that it's good enough for _some_ KDE=20 users and developers and the KDE development model should reflect that. > how about=20 > telling the app developers KDE-3.1 is still good enough? Then they'll > have stable framework as well, won't they? They'll be in the same > position WRT KDE just like you suggest we should be WRT Qt. I never said that kdelibs vs. Qt is any different from kde apps vs.=20 kdelibs. > > 3. more testers for HEAD apps since thay can check out > > bleeding-edge apps on a stable desktop. > > Perhaps. But I _you_ > run HEAD apps from time to time in my _your_ I'm not talking about a KDE core developers here. I'm talking=20 about people that want to track Kontact development b/c it's cool and=20 don't want to update the complete framework just to be able do so. I'm=20 talking about intermediate app releases targeted at the latest stable=20 KDE release. > stable KDE, and =20 > they work too. If one can compile HEAD app, they can compile > Qt+kdelibs as well. It's *much more* work to set up multiple KDE versions. It's several=20 orders of magnitude easier to just build a single KFoo app or kdebar=20 module: rpm -Uvh {qt,kde}*devel*.rpm =2E/configure make [make install] > > 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. > > 3. One can't use new features. Pardon? Ever heard about #ifdef KDE_IS_VERSION(...)? Just deactivate the=20 feature if compiled against the old lib... Where's the problem? > > 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. > > And also from (c) the fact that shit happens, and theory and > practice in practive sometimes differ. E.g. Qt-3.0.1 and Qt-3.2 are > not quite compatible when it comes to certain small details (like the > plugins, changed around 3.0.3 IIRC). > [snip] Did these changes break documented behaviour? If not, then this was a=20 case of layering violation. If it was, it's a Qt BIC or SIC bug. If Qt=20 doesn't keep BC and SC, why should KDE then try? Marc =2D-=20 Kight, Khis Kay KDE Krogramms Kre Kasier Ko Kdentify; Gnome Grograms Gn Ghe Gther Gand Gtart Gith G. -- "diskord_" in heise.de newsticker comment (translated) --Boundary-02=_CktJ/5WqW/o8d4w Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/JtkC3oWD+L2/6DgRAsT/AKCyr5sjRzVWwBDpMCR0ncuyZDG9FwCg5kSY iATFwUH8wqlbUZRsY+/ZB68= =L3YC -----END PGP SIGNATURE----- --Boundary-02=_CktJ/5WqW/o8d4w--