14 DAY TRIAL // A few months ago, Google announced that it would be speeding up release cycles for Google Chrome. Since the team was already churning out new versions at an unheard of pace for desktop software many wondered less whether Google could do it, but why would it want to in the first place.
In the mean time, the Chrome team has indeed been getting new releases out there every six weeks, like the accelerated schedule required. But, of course, six weeks is not enough to get much done, so each new version doesn't really bring major improvements, rather just a number of new features.
But that was the plan all along. Chrome product manager Anthony LaForge has now explained the rationale behind the new release schedule as well as the problems Google had implementing it.
Previously, a new version of Chrome came out once every 13 weeks or so. While much faster than everyone else in the game, new versions still carried some weight and usually came with a number of touted features.
The emphasis was on getting a list of features done before each release, which meant pressure on the teams to get their work ready by the release date and also meant a lot of work merging all of the different patches into the production releases.
LaForge explains the way things worked before. "[For final beta Google would] cut a branch (when we thought we had everything), merge about ~500 patches (since we didn't have everything), [and] spend weeks stabilizing and re-stabilizing issues," he explains in a Google Docs presentation he made public.
"[The Chrome team] Ended up working 1-3 months to get a release out the door, always certainly missing our 13 week plan," the presentation read. "And at the end finally shipping something we were happy with... but that left us pretty drained (i.e. the bad flow)."
The idea behind the new six-week release schedule was not just to speed up the process, that would only make the problems worse. Instead, the idea was to change the way new versions were created.
Instead of focusing on getting a certain list of features into each new version, there is now a fixed schedule and whatever is done before the release date gets in, the rest gets pushed to a future release.
This means that engineers can spend the time they needed to get the feature they're working on just right, and it also means that releases are always on time.
For this to happen, as the builds go through the beta phase, features that are not ready for the prime time are dropped from the codebase and nothing new gets added. This insures that a release is made available on time regardless of what gets in or not.
"We basically wanted to operate more like trains leaving Grand Central Station (regularly scheduled and always on time), and less like taxis leaving the Bronx (ad hoc and unpredictable)," LaForge explained. Check out the full presentation for all the details. [via TechCrunch]