After Firefox 4, the Mozilla community decided that we needed to be more agile and ship Firefox faster. This “rapid release” process has been absolutely fanstastic for the Mozilla engineering/development community: we have been able to develop more quickly, and the process has made Firefox development a lot less stressful because there will always be another release in 6 weeks. But rapid release has its downsides, and I think we, as a community, should consider whether we are serving the needs of our users.

Much has been said about how the rapid release process is problematic for “enterprise” users, or other situations which use managed deployments and have unusual testing requirements. I know that we are discussing a plan to work with enterprises to provide a longer-term support system for these users.

But even for ordinary “consumer” users, there is still a significant pain point in the rapid release process. Not all extensions are keeping up with rapid release. Traditional Firefox addons are given almost infinite power to modify the application, but with this power comes a price: any change we make has the possibility of breaking an addon.

We are working on many projects to mitigate this problem. The Add-on SDK (Jetpack) gives addon authors a way to write addons against a stable API that we promise will be maintained across versions. And most of the time, even though an extension is actually compatible with a new version, we aren’t sure about this compatibility. We are planning on asking our Aurora/Beta testing audience to help us test addons to mark them compatible by default.

But even with all these mitigation strategies, there are still going to be users who have incompatible addons on each 6-week cycle, either because they are using unusual or custom addons, or because an addon which is critical to that user needs major update work which cannot be completed in a particular release cycle. Users are then given the unfortunate choice of updating Firefox and having important extensions broken, or not updating Firefox and potentially being exposed to security flaws.

We should continue the existing rapid release process: it makes our development practices better, and for a majority of users it gets them the newest and best web features and Firefox performance improvements as quickly as possible. But for users who have a long tail of addons which are updated less frequently, we should complement the rapid release vehicle with a stable release which will contain security fixes but won’t break extensions for a longer period of time. This could be a release vehicle which has updates only on a 6-12 month cadence.

This is definitely not an easy decision; maintaining a stable version will cause pain for our community. The development community will have to do security/stability backports against older code. Our testing community will somehow have to deal with an additional train of releases beyond the existing nightly, aurora, and beta release trains. We will have to deal with pressure to rush a feature into an stable release, or delay the schedule in order to pick up an important feature. Finally, a stable release will be a pain for extension authors themselves, because extensions must provide and maintain versions which are compatible with both the rapid and stable releases.

I fear that we are frustrating our users with extensions, which ought to be one of Firefox’s greatest strengths.

This entry was posted on 15 Sep, 2011 at 6:51 pm and is tagged with . Trackback.