Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
Alexander Neundorf
neundorf at kde.org
Mon Jul 26 21:00:10 CEST 2010
On Sunday 11 July 2010, Sebastian Kügler wrote:
> On Thu July 8 2010 17:36:09 Maciej Mrozowski wrote:
> > Hello
> >
> > From what I understand, Plasma in KDE4 Workspace 4.5 relies on
> > notifications provided by libdbusmenu-qt to control what to draw in
> > system tray. And apparently Qt <= Qt-4.6.2 contains known bug that causes
> > 'close application' notifications not to be delivered - as a result
> > causing system tray regressions - application icons not disappearing.
> >
> > https://bugs.kde.org/show_bug.cgi?id=232915
> > https://bugs.kde.org/show_bug.cgi?id=195998
> > https://bugs.kde.org/show_bug.cgi?id=241248
> >
> > and similar reports.
> >
> > Because it's quite visually exposed and obvious bug (confirmed to be
> > solved with mentioned Qt upgrade), I propose bumping Qt requirements to
> > 4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it
> > requires Qt 4.6.0).
>
> We need to communicate clearly that we really require the latest Qt for our
> software to work well, that's something we'll add to the release notes
Hmm. Compile time vs. run time dependency, ok.
But here you say "we *really* require the latest Qt" and that we have to
communicate that clearly.
IMHO the clearest and most obvious way to communicate this is to increase the
minimum version of Qt to 4.6.3. Even if this version is not necessary to
build, but "only" to make KDE run better.
I know, people can still build against 4.6.3 and then run against 4.6.0, but
this would be more or less intentionally violating what we recommended.
I know that packagers don't like putting things in the build requirements
which are in strcitly speaking runtime requirements, but at least when I
build from sources I would prefer that the software tells me at build time
whether my versions are ok or not.
I would expect that if I have met the minimum required versions of a software,
that it will work properly once it has been built successfully. So,
basically, I would favour blacklisting bad (but compatible) versions.
Alex
More information about the release-team
mailing list