[Releasing] Bumping Qt 4 version to 4.8.5

[Robin Burchell]

On Tue, Dec 4, 2012 at 11:08 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> Here's a question to the project: do we want to merge (-s ours) the releases
> from vendors into our official tree? And do we want their tags too?

Speaking with my Mer Project (/Jolla) hat on:

I don't think direct merges would work, at least for our case.

There are sometimes changes we have that cannot be upstreamed. For
instance, we (still) have MeeGo's XInput2 patch against Qt 4, which we
can't apply, thanks to the rules of the branch. We also have a bunch
of changes that would equate to a QtQuick 1.2, and I'm guessing that
isn't really acceptable upstream (even if it would probably be nicer
both for the users of Qt, and for me when looking at our large patch
delta...).

We also don't really do tagging, as our release process happens
separately from the git tree. I maintain our packaging as the upstream
tarball plus a set of patches, as I'm firmly convinced that there's
less "bus factor" there than distributing a massively hacked up
tarball. I do have a git branch published
(https://github.com/rburchell/qt), but like the warning on the tree
says, it can (and is) rebased often.

I do encourage (and participate in) pushing stuff upstream where that
is possible though, and some of our changes (like allowing
configuration of QApplication's startDragDistance property) might be
useful to push, but I'm unconvinced that our current approach (an
environment var) is the best possible solution - but haven't been able
to think of a better one, either :-).