The strange world of (release) candidates

You’ve seen the news: the first release candidate for Qt 5.0 has just been released. .And if you haven’t, you can go download it from http://qt-project.org/downloads. I’d like to first of all congratulate everyone involved in getting it out, with a special nod to the release team. Thanks for all the work!

But I’d like to talk about what will exactly happen in the next couple of weeks from now until the 5.0 final.

If you’re familiar with previous Qt releases, you may have noticed that our release candidates weren’t really release candidates. In particular, the release plan called for exactly one release candidate and we knew the time between that release and the final. We also knew that the release candidate wasn’t really a candidate because there were still changes we needed to make. Finally, after those changes were in — and some of which were quite significant — we released the final directly, without a second release candidate.

No more. This time, we’re doing it the right way. More importantly, it’s all done in the proper, Open Source and Openly Governed way.

The Qt 5.0 Release Team is composed of people from many different companies, not just one, testing many different platforms. We’ve released the alpha, the two betas and this release candidate as a group. Sure, there have been growth pains, especially in the Beta 1 release, but those have mostly been ironed out now.

The last mistake we fixed was one that I had unfortunately caused: in order to support the Tier specification for the 5.0 release, I had required that packages produced by the Qt Project be tested for 48 hours before they could be released. The idea was to make sure that everyone got the chance to participate in the release process and especially the opportunity to find and fix bugs on their platforms before the release went out. And that’s what we were doing for the Release Candidate.

Then it dawned on me: that IS the release candidate model. In other words, we were doing release candidate release candidates!

After a discussion on Monday’s release team meeting, we agreed to drop that indirection and just do regular release candidates. Here’s what we’ll do on releases from now on:

1. Release team prepares a package set;
2. Release team does a sanity check on the packages:
   • did the build succeed?
   • do the packages include the latest / correct commits?
   • do the installers work?
   • etc.
3. If the sanity check went ok, the release team releases this package set as a new release candidate;
4. For a week, we’ll collect bug reports and other issues, as well as fixes;
5. Then a subjective decision needs to be made: do we have outstanding showstopper issues? Were there any important changes that require wide testing?
   • If so, go back to the first step and let’s do a new Release Candidate;
   • If not, repeat the packaging and sanity-checking steps but for the Final.

We released RC1 today and I can bet we will find issues that require intrusive fixes. That means you should expect an RC2 package in a week or a week and a half. Hopefully, that RC2 should be the last we need, though.

So, please, get RC1 now, test it and let us know. There’s usually a lot of helpful people in the #qt-labs IRC channel on Freenode, especially during European daytime. And any issues you find that could potentially be showstoppers, file them in our bug tracking system at http://bugreports.qt-project.org.

Let’s try and get the final out by the end of the year.