Google Chrome and the Release Cycle

Back when Google Chrome debuted, I thought it an interesting concept, but not something I would ever use. I was a Firefox diehard. I was one of the few who could (or at least would) admit to never having willingly used IE. Even during the dark days of IE dominance, when Netscape 4.76 was the only competition in the land, I still refused to move over to the spinning ‘E’.

So, one year ago, when Chrome gained extensions on the Mac, I decided I would spend one month testing to see if it was usable. That one month has very quickly turned into one year. Despite the great leap forward Firefox 4 is showing to be during its beta period, I still don’t see myself returning to it anytime soon. The release management differences between the two competing browsers is, in my opinion, a lens into my reasons for switching.

Back in July of last year, when Google announced that it would speed up the Chrome release cycle to a new version every 6 months, I was at first incredulous and secondly, I thought it preposterous. Really? What kind of major coding could you get done in 6 weeks that would necessitate an increase in a major version number? It wasn’t until I came across this set of slides that I came to understand the answers to my questions:

Reading through the problem, I can see why they moved to the cycle they did. I can’t say I blame them as the end of a release cycle is always fast and furious. We tell ourselves, never again will we do this, yet a few months later, we find ourselves doing the exact same thing.

The decision to focus on features and not on release numbers or date driven development is impressive, but sadly probably not an option for most of us who are not Google. I don’t think that most non-IT management, and even a lot of IT management, really gets what its like to work a well-run development cycle. It is hard, but giving them a solid date and a version number gives many of them a false sense of understanding because numbers and dates are something they 'get’. If we tell them we have a plan for delivering v17.9 on January 31, then that’s great, right? Well, maybe.

But what about that line that discusses disabling features with a single, small patch? This I like. I always wondered how features that take months to develop could be held safely during all that time. If a developer kept all that code on their local drive, which then had a failure the day prior to completion, all that work would be wiped out. Sure, private branches in version control systems could be used, but they clutter up your system with a bunch of dead branches once you’re not using them any more.

Another advantage I see is that by doing this, you force the developers to keep dependencies between code modules at a minimum. If any feature can conceivably be disabled with a single patch, you ensure a better, more maintainable architecture on your application.

The last thing that stood out to me was really a question. If you move to 6 week upgrade cycles, why do you really need a version number at all? Sure, its easier for us as humans to remember 'v17.9’ than it is a build number output by some compiler, but really, does a version number matter at this point?

From a purely logical standpoint, I don’t think it does. Google could still put out a press release every couple of months touting a new release of Chrome that includes feature XXXX or decreases page load time by 17%. They don’t need to specify a version number, just that 'you’ll be getting it soon’. For the 'About’ page in the browser, you just need to know if you’re 'up to date with the latest browser version’ or if you need to do an update.

Sure, you can say that having v17.9 sound more advanced than having v2.7, but versioning has always been at best an art and at worst, a marketing farce. I am just beginning to wonder if we shouldn’t start working towards the 'post release number’ era. I don’t see that they provide much worth in the modern world.