[Releasing] Bumping Qt 4 version to 4.8.5

Thiago Macieira thiago.macieira at intel.com
Tue Dec 4 23:08:15 CET 2012


On terça-feira, 4 de dezembro de 2012 18.21.17, Vladimir Minenko wrote:
> Ok... Well, I can also ask a good question why you bump the version to 4.8.5
> before it is actually released. You probably will have a good answer,
> likewise I will also have a good answer why bumping the version disturbs
> our integration right now. But, all this does not help by the end of the
> day...
> 
> In short, 1) we cannot wait for official 4.8.x releases and work directly on
> the master, 2) we have no time for manual cherry-picking into an internal
> branch and decided to take all commits as long as a snapshot passes our
> testing.

That's your choice. But I recommend against that, since you're taking a set of 
commits that haven't been tested by anyone else. In fact, it's extremely 
risky, as was shown in the fact that we had a forward binary compatibility 
violation for a few days in the 4.8 branch. Suppose you had released that: in 
that case, the next release would contain a backwards binary compatibility 
violation, which is orders of magnitude worse.

I'd much rather that you participate in the Qt 4.8.x release cycle and release 
the exact same thing (Tier 1 behaviour). Or, in the worst case, a few extra 
commits that are specific to QNX only, by taking the 4.8.4 tag and applying 
only what you need to make your release (Tier 2 behaviour).

> As mentioned in my previous email, changing the version of Qt changes the
> version of the so libs, which we have to reflect while building device
> images. Sometimes, there is just no time for this, and an entire update of
> Qt in BlackBerry 10 is in danger to get stuck. We currently just cannot
> afford this!

Indeed, you can't afford that, you can't afford a binary compatibility break, 
and you can't afford a lot of other things. The only sane thing to do is to 
control *exactly* which commits go into your release, by branching out.

If you're doing this as a vendor release (Tier 2 behaviour), then you need to 
send the commits to the 4.8 line in parallel via Gerrit. We'd all appreciate 
if you also make the Git tree and tag of your release available.


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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20121204/d5ccb220/attachment.sig>


More information about the Releasing mailing list