We all want to get access to new features, but we also want to get stable things. These two goals seems contradictory and in a sense they are. If you want to live in the edge you have to accept some "early adopter problems" but if you want to have only rock solid features, you need to let them mature and "gain experience". With our new open development process people can get access to all of our newly developed features while they are still in the making, therefore gaining valuable insight on what's coming in the next release. The problem appears when people uses that "bleeding edge" code to start developing things, how can we provide "stable bleeding edge" features?
The solution is more or less obvious, have a master branch where everything is committed and a master-stable branch that is slightly behind master but it is guaranteed to compile. It seems simple and problem free, however there is still one pending question. How "slightly behind" is master-stable from master? Up to last week, master-stable was manually updated, which led to fewer updates and not so "bleeding edge" code. From this week on we have implemented automatic update of master-stable, so now master-stable will be updated as soon as everything is ready, no human intervention required.
The system goes like this:
- Whenever there is a change committed to master, that change triggers a build in all of our tier 1 platforms.
- If the build is successful, then a build on all of our tier 2 platforms is triggered.
- And if that build is successful, our CI system will push changes from master to master-stable.
Voila, master-stable updates itself! So from now on you have no excuses not to use master-stable to check out what's happening in Qt while enjoying a "stable bleeding edge" branch.
The avid reader would have noticed that it is the first time my name appears on this blog. I joined Trolltech on September 2007 and I've been the QA manager for Qt for the past two minor releases (4.4 and 4.5) and currently I'm busy handling Qt 4.6 :-)
.webp)
