If you’ve filed a bug, translated a string, written code, worked on an add-on, supported the development infrastructure, or helped to explain Firefox to someone else, you were part of making Firefox 3 a success.  I’m excited, humbled and proud of being a part of this amazing event.   I hope you are as well!!

What’s next? That’s simple: our next challenge is to deliver releases of the quality and impact of Firefox 3 with much greater frequency.  As part of this we are going to start doing smaller, shorter, more date-driven releases to stand in-between the Major releases (like Firefox 3) and security updates (like 2.0.0.14).   The first one of these is tentatively called Firefox 3.1 and is targeted for the end of this year.  This is a chance for us to continue to improve features like the awesomebar and to deliver advances to the core web platform at a fast clip.  We’ll do this work in parallel to the larger architectural work underpinning the next major release called Firefox 4 that will ship much later.

Ever since the release of Firefox 1.0 in 2004 we’ve had basically two kinds of releases:

Security and Stability Releases: the 0.x or 0.0.x series – these were strictly limited to security, stability, and small performance/footprint wins with an emphasis on security.  They were and are restricted in their scope to make the upgrade seamless and easy.  We pledged to not break add-ons or change user visible features in any obvious way to remove any concerns about upgrading.  This discipline, in combination with our awesome update code and infrastructure, is the reason why 90+% of Firefox users are using the latest version within 7 days of release.

Major Releases: Firefox 1.5, 2, and 3 are major releases.  These releases are an opportunity for us to add new features, polish existing ones, and implement and test new features for the web platform.  They may involve significant new features (places) and/or significant re-architecture of core components (reflow refactoring, cairo graphics, etc).  The longer development cycle gives us, web developers, and extension authors the requisite time to test everything before release.

Over the last several years a couple of key things have changed:

1. Our community has grown dramatically – allowing us to get more done at once
2. Our systems from release, to unit test, to performance analysis have gotten much more robust allowing us to make more changes with confidence
3. Our recent move to Mercurial makes branched development much less costly
4. The web is moving at a much faster pace, from new spec development to expectations from web authors about when they can use new features like offline web apps (this is a great thing!)

These changes have lead us to propose a new (for us – not new in the world!) release category:

Minor Releases: The proposed Firefox 3.1 release fits into this category.  Unlike security releases we can add new features or change functionality of existing ones. This includes user-facing features and web platform features.  The scope of these releases is by definition much smaller than Major Releases – so the scope of changes, testing time, etc will much reduced. These smaller releases will give us an opportunity to deliver upgrades to the core functionality of the web sooner and continue to keep us agile in responding to changing needs of users and web developers.

To put this another way:

• Typical security release: 6-8 weeks (e.g. 2.0.0.14)
• Major Releases: 11-20 Months (e.g. Firefox 4, Firefox 3, Firefox 2)
• Minor Releases: 5-9 Months (e.g. Firefox 3.1)

We’ve already been doing 3 streams of parallel development (1.5.0.x, FF2, and FF3).  Our recent switch to a distributed version control system and our growing development community are allowing us to, in general, develop in a much more parallel manner.   Initial Firefox 4 work started almost a year ago and folks have already been cranking on Firefox 3.1.  But the branches are wider than that – you can see from the initial platform planning here that individuals and teams are focusing on particular feature or architectural areas and deciding whether is small (ready in 2-3 months), medium (6 months or so), or large (longer or not enough understood to fairly estimate).  Firefox 3.1 will include the set of smaller tasks that are ready in time.  Medium and larger tasks are being worked on in parallel so we have a constant stream of improvements ready for a release vehicle.

Whew!  Still there?  Now I realize that parallelism is no panacea and carries with it many challenges.  It will strain us in everything: people, tools, and process.  But our development community is talented, our tools are getting better, and our planning is getting smoother with every release.

I know we can do this together – you with me?

P.S. Further background on this discussion here.