Qt 3.2 requirement

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 30 July 2003 02:37, Marc Mutz wrote:
> >  o having to work around bugs / misfeatures that are already fixed in
> > Qt 3.2
>
> So, what about the poor KDE 3.1.x users? Are they stuck with the bugs?

no... i'm talking about HEAD... as Waldo prudently suggests, 3.1.4 should be 
made to work with Qt 3.2 and that's that. in addition, we should continue to 
backport bugfixes as work on the 3_1_BRANCH as we fix them in HEAD. 

even then, backporting bugfixes and keepin Qt 3.1 in mind is FAR easier than 
trying to develop HEAD with both Qt 3.1 and 3.2 in mind. this is because far 
more work occurs on HEAD, and usually it's far less trivial than the bugfixes 
that get backported.

> > o having to keep multiple versions of Qt around for testing.
>
> You don't need to. Others will fix errors as they fix incompats with
> other compilers/OS'es. The important thing is that those fixes must not
> result from someone willingly breaking backwards compat.

sure, if someone wants to play Qt 3.1 janitor, great! i almost suggested such 
a thing in my email but then thought, "who would spend their time doing so?" 
no, things would get missed anyways and people's time spent on janitorial 
duties may as well be spent compiling Qt 3.2 and improving CVS HEAD ;-)

> > o having to maintain multiple code paths which you may or may not be
> > able to test thoroughly.
>
> Noone can seriously tell me she tests all code paths in her application.
> You know that's both impossible and not necessary. 

we don't need to make the situation worse by adding yet more code paths, do 
we? of course not.

> Replacing a self- 
> coded feature with it's equivalent implemented upstream has very little
> potential for bugs once the new version has been debugged (which has to
> be done anyway, I might add).

it isn't simply the initial implementation that is error prone. you are right 
that this is the safest point in that code's life (assuming you do actually 
check against both Qt versions). but then someone else comes along and makes 
a change elsewhere in the code that precedes or comes after it in the code 
path. they only check it with one version of Qt. this happens again and again 
and the ifdef'd code paths diverge. so unless all the ifdef'd sections are 
checked in a code path whenever changes occur to it, problems will eventually 
arise.

this is especially important for applications like KMail where the codepaths 
are often long and winding. this is a challenge to multiple version compat. 
those who choose to do so are welcome and have my greatest respect. i'm 
simply concerned about requiring all to do so.

> > all of the above leads to:
> >
> >  o longer development time
>
> For the framework developer? Maybe. For the app developer? Hardly. Since

no, it will lead to long development time for the app developer by having to 
maintain and verify two distinct versions of their software.

> this is a discussion on _Core_ Devel, I don't expect people here to
> agree that the framework nowadays is so much less important than the
> applications from a user perspective, but it is. 

i agree that the applications are much more important: without them, why have 
a core?  see, you shouldn't assume so much about what others think ;-)

> The more I wonder why 
> extremely tiny framework enhancements such as adding a new std action
> need to be immmediately commited to all CVS, breaking application's
> backwards compat and forcing an immediate upgrade of the whole kdelibs.

again, there are arguments for and against: time compiling, version compat, 
consistency across applications, etc, etc... but here's a tip (which i'm sure 
you already know, actually): for things like stdactions, just update the 
subdir of kdelibs you need (e.g. kdeui) and build just that part... you can 
almost always get away with that and it saves a ton of time.

> If you've done this, you can forget your incremental builds and devote
> half a day to recompile your modules. Now, that's what I call
> development time saving! ;-)

yes, i've lost time to this as well... which is why i was one of the people 
who pushed for a library change commit day (which is theoretically Monday/
Tuesday now)... however, this has nothing to do with our original discussion 
of adopting Qt 3.2.

> >  o more obfuscated code thanks to ugly #ifdef'ery
>
> If a lib upgrade shows that you've relied on undocumented features, then
> you should not #ifdef another workaround but instead find a solution
> that works with the documented features. If you can't, refactor so that
> the code with the intimate lib knowledge is in a single place, then
> #ifdef only there.

this isn't the only reason for #ifdef's... there are changes such as the 
QString::find changes Kulow pointed out. i'm thinking both feature additions 
and bug fixes that no long have to be worked around.

> Ifdefs have the nice side effect that they're easily grepped for. So if

> through CVS and remove #ifdef QT_VERSION < 0x030200'ed code. That's a
> newbie task. OTOH, if you see un-ifdef'ed code with a "workaround"
> comment, then (1) you can't easily grep for them and (2) a newbie won't

oh, of course! but again, this has nothing to do with whether or not we should 
support two version of Qt simultaneously. i'd rather see ifdef's go away ASAP 
rather than create a situation where we actually encourage more of them in 
the code at the expense of code readability and contributor's time, easy to 
remove later or not.

> >  o hightens the chance for bugs in code left there for backwards
> > compat but which few (if any, in some cases) of the developers use
>
> See above. To the contrary.

you are the first person whose coding abilities i respect that i've ever 
talked to who has said that ifdef'd code paths in your application reduce the 
possibility of bugs.

> >  o bugs in the code that appear when run with one version of Qt but
> > not another (the recent konq sidebar commit that relied on Qt 3.2 was
> > a good example of that)
>
> "Bugs in code". Hmm, do I understand the above correctly as saying "it's
> better to not have multiple version compat, since it might uncover
> hidden bugs in our code"? ;-)

no, better not to have multiple version compat since it might (and i'd posit 
that it _will_) create obscured bugs in our code. they will be obscured 
because they will show when running one version, but not another. so only 
some will have the opportunity to see the bug. and if the bug is not purely 
local to the ifdef in scope, then things get even more tricky.

> >  o less people testing what will be the common version of Qt+KDE when
> > KDE 3.2 arrives.
>
> Nope. I'm not advocating that KDE 3.2 should be compatible with Qt 3.1.
> I'm advocating that the Qt 3.2 requirement only gets kicked in place
> once the feature freeze is in place.

and i'm saying that the sooner we can get people testing that combination, the 
higher the chances for imperfections to be discovered and the more time we 
will have to fix them.

> requires Qt 3.2. Since KDE 3.1 libs apparently don't work well with Qt
> 3.2, development of the PIM suite cannot continue using stable kde core
> libraries. I'm not denying we've been already past that point when this

this is solved by making KDE 3.1 work with Qt 3.2 nicely ... think about: one 
period of time resolving the (relatively minor, it seems) issues with KDE 
3.1/Qt 3.2 rather than multiple periods of time supporting Qt 3.1 in CVS 
HEAD.

> > 3.2 proper this isn't an issue, it's really only an issue for
> > applications that will be a part of 3.2 that wish to do independant
> > release between now and then and for developers who couldn't be
> > bothered to compile 3.2 themselves.
>
> Or for commercial projects

yes, i see all applications released outside of KDE release cycles as "3rd 
party" efforts...

> that are contracted to deliver a product that 
> runs on the latest stable KDE release and want to be so nice as to work
> with the community. Either those projects will work w/o the community
> in the dark and appear with a large amount of code to merge (like
> Safari), possibly with an unacceptable approach to the problem so the
> work is lost for KDE 

Safari is a wildly different sort of project in that it doesn't even use Qt 
(!) and was developed behind closed doors likely more for marketing reasons 
than technical ones. i don't think it's relevant to this discussion... that 
said...

a 3rd party project that wishes to write an application against a stable KDE 
version can indeed keep multiple version support themself, and even put it 
into KDE CVS should the application maintainer wish. they are neither 
hampered not helped by KDE's choice of Qt version for CVS HEAD.

a 3rd party project that wishes to enhance a core KDE library can do so, but 
should be aware of the KDE release cycle. otherwise KDE has to shift the 
entire project for those efforts. KDE's release cycle is a good one and not 
out of line with traditional cycles as far as time goes (in fact, i'd say 
it's usually faster and more on-time).

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/KBHN1rcusafx20MRAtkaAKCi42AK8txHZi2suH2YT9uLj910GwCfZuM4
DDoq4udmmOCpAhDWyIA2iYs=
=7Ged
-----END PGP SIGNATURE-----