(Disclosure: I work for Mozilla.)
Anthony Laforge, the Google program manager in charge of Chrome releases, was kind enough to give a talk at Mozilla's all-hands meeting in December. He gave a version of this presentation: http://techcrunch.com/2011/01/11/google-chrome-release-cycle...
Each Chrome release is in development for 12 weeks. There are always two 12-week cycles in progress at once, staggered by 6 weeks. So users on the stable channel see a new version every 6 weeks.
This has benefits much more profound than just a large number before the dot. For example, developers working on new features actually feel less schedule pressure. If a feature misses the deadline for version N, the team knows they'll have another chance just six weeks later for version N+1. And for users, the browser becomes more like a web app. Do you know what version of GMail you use? Do you notice every time they add fix bugs or improve performance on Google Maps? No - every time you open the app, you simply have the latest version.
Laforge mentioned some things about Chrome development that make this work:
- Silent background updates. When an update is available on your channel, Chrome downloads it in the background and installs it. The next time you launch the browser, it is running the new version and deletes the old one. Because of this, the majority of Chrome users are up-to-date within days of each release.
- Feature switches. Development is done on trunk, but each work-in-progress feature can be disabled with a switch (either a preference, a build option, or a command-line flag). This lets developers work for several cycles before turning a feature on for the stable channel. It also lets product management disable a new feature if bugs are found during beta, without changing any code. Web startup folks might recognize this as the "always ship trunk" pattern used by sites like Flickr: http://news.ycombinator.com/item?id=1463751
- No support for old versions. Instead of deciding which "version" to install, Chrome users decide which "channel" to follow. If you are a developer and want to test upcoming changes, use the canary or dev channels. If you want a more tested browser, use the beta or stable channels. New features roll out to each channel in turn. If you are on one of these four channels, you get updates. If you are not, then you don't. (Just like you can't choose to run an old version of GMail or Google Reader.)
Mozilla is just starting to talk about the new roadmap and how to achieve it. Chrome's experience is useful, and it was really helpful of Laforge to share it with us. But we're different both technically and organizationally from Chrome, so just blindly copying what they do would not be a good idea. The wiki shows a plan for releases every 3 months (not every 1.5 months like Chrome). We use Mercurial with long-lived project branches (unlike Chrome which uses Subversion and does all development on trunk). And our product differs in some important ways, like the ABI for binary extensions. (Even non-binary Firefox extensions may reach deeper into the browser internals than Chrome extensions.)
But we do think that the benefits for users (more frequent improvements to the browser) and developers (more predictable schedule, fewer release delays) are worth pursuing. There are benefits for web developers too, since it reduces the time from when we start implementing new web-facing features (like IndexedDB, or CSS3 transitions) to when you can deploy them to more of your users.