Sustained Engineering: Patch builds
In January we merged the QA and Support teams into one organization with me (QA Director) heading them. The main purpose of this merge was to enable us to do sustained engineering on our growing number of versions, such that we can better handle the issues our customers face in current released versions. By “sustained engineering” we mean working hard to improve the reliability of a currently shipped version of Unity, and not making fixes in future versions which can take time to complete, pass through alpha and beta cycles, QA fully, and ship. Effectively it is an expansion of the responsibility of the support team to also be able to fix bugs, backport bugs and release them directly to customers as patches.
Since the support team is not of endless size and the risk of making code changes on a released version is high, we are going to be very careful about which bugs we will fix. Pieces of the puzzle include the severity of the issue for the customers, the amount of customers affected, how long it will take to fix and a slew of other factors. The bottom line is that we will not be able to, or even want to, fix everything everyone asks us, but we will be able to do more than we do today and do that more often. Customers affected by annoying bugs should see these problems resolved much more quickly.
To be able to handle this, we have recently hired a release manager, Jawa, to handle the release train for these patches. He will handle the communication internally between all the teams in Unity and also handle the release procedure for each of the patches and update the forums on releases.
When we say patches, it is actually a full release of the entire editor, with all runtimes. The complexity of Unity forces us to do that. However, if you are hit by the issues we fix, it will be available on our forums for you to download, just like any other version of Unity you use. The main difference is that we will distribute the patches through the forums and we will NOT enable the editor update check on them. A patch will have a version number ending in “..pX”, so for example, a patch for Unity 4.3.8f1 will be called 4.3.8p1. This patch will have a small number of bugs fixed. These bugs will be listed in the release notes for that version. Then a new patch will be generated, which will include these fixes, and newly fix bugs. This will be 4.3.8p2, and so on. Once we have a set of patches ready, we will roll them up to a new “..fX” (f for Final) release, eg. 4.3.9f1, and that will undergo full regression tests and be enabled through the editor update checks for everyone. Note that we expect only customers affected by reported fixed bugs will want to migrate to patched versions of Unity.
To really kickstart this journey, we have gathered support engineers, field engineers, QA, build engineers, infrastructure engineers and release managers in Brighton this week. A total of 28 people have joined in a week of learning the processes, doing the actual fixes and shipping them. I will have to caveat that the focus here is on learning a very hard process of getting the code done right, it is NOT about having large quantity of fixes, so the first few patches will be very limited.
It has been fantastic to see everyone working on a common goal for a week and it is fantastic to be able to present you with the very first results. Join us on the next journey and check the first patch here: http://forum.unity3d.com/threads/246198-Unity-Patch-Releases