Mozilla outlines 16-week Firefox development cycle

Mozilla Firefox logoAlthough Mozilla is still readying Firefox 4 for its official release, the organization is already laying out its plans for subsequent versions of the open source Web browser. In a roadmap published earlier this year, Mozilla revealed plans to issue three more major releases during 2011--bringing the browser's version number up to seven.

As we discussed in our coverage of the roadmap, Mozilla's plan is ambitious and will require a dramatic overhaul of the Firefox development process. Mozilla—which has historically had lengthy development cycles and protracted beta testing—will have to transition to a faster and less-conservative approach to release management. The organization has authored a document that describes how such a transition could potentially be achieved.

The document is still in an early draft stage and should be regarded as a proposal—not a finalized product plan, but indicative of the organization's thinking. Although it leaves some questions unanswered and there is still room for refinement, the strategy articulated by the document is compelling and illustrates the importance that Mozilla places on properly executing the procedural overhaul. Mozilla is clearly putting a lot of thought into this effort and is laboring to ensure that the transition will best serve Firefox's audience.

The document describes a 16-week development cycle in which software improvements will flow down through several tiers. The tiered model appears very similar to Chrome's channel system. New code will initially land in mozilla-central, the repository that hosts the tip of the code base. As new features solidify, they will roll through "experimental" and "beta" channels before arriving in a stable release.

Each of those tiers will be backed by its own code repository. Features will have to be implemented in a more compartmentalized fashion so that Mozilla can easily disable or withdraw functionality that is deemed unready for the final release. The proposal draft estimates that roughly 100,000 users would run nightly builds based on the code in mozilla-central. This group would likely consist of Firefox developers and contributors who are willing to tolerate some breakage and day-to-day changes to the user interface.

The experimental channel, which would have an estimated test base of roughly 1 million users, would be ideally-suited for Web developers who want to test the latest standards and Firefox add-on developers who want to experiment with new browser APIs. Beta releases, which will be suitable for widespread testing, are expected to attract a broader user base—as many as 10 million, according to the proposal.

It's worth noting that Mozilla already publishes nightly builds and beta releases. There isn't, however, anything that is quite analogous to the experimental channel in Mozilla's current pr-release lineup. Interestingly, the number of users actually running prerelease builds today is seemingly a great deal smaller than the estimates in the proposal.

The document describes a powers-of-ten pattern of audience growth between the nightly, experimental, and beta channels, but it's not really clear where that is coming from. To put it into perspective, it's worth comparing against a chart that Mozilla highlighted in November which cites 20,000 nightly build testers, 800,000 Firefox 4 beta testers and approximately 400 million users. Keep in mind, of course, that the proposal document is still a draft and there could be any number of possible explanations for the odd discrepancy.

One of the challenges posed by faster iteration is the intrusiveness of the update process. Frequent updates would be especially disruptive to users running the experimental and beta channels. The proposal document suggests silent background updates as a potential solution to the problem. It's worth noting that Mozilla is already transitioning to silent updates for minor fixes in Firefox 4. It will be possible for users to opt out if they prefer to manage updates themselves.

Arguably the biggest challenge for faster iteration is going to be the question of extension compatibility. The proposal document acknowledges that the problem exists but doesn't provide any suggested solutions. It's an area where Mozilla is going to have to do some serious problem-solving.

Firefox's robust add-on ecosystem is one of the browser's strongest differentiators, but keeping add-on developers aligned with the latest version of the browser is already a big challenge. Shortening the development cycle is going to exacerbate that issue profoundly. Users tend to not want to update until their favorite add-ons are compatible. Before moving forward with an incremental development strategy, Mozilla is definitely going to have to flesh out a plan for dealing with the extension issue.

Again, we want to emphasize that the proposal document is an early draft and there is still a lot of space for changes and improvements before Mozilla puts a plan into action. The real value of the document at this stage is that it shows how Mozilla is thinking about the transition. I still remain skeptical that Mozilla can deliver four major releases in one year, but the process proposal is a good first step that adds credibility to the existing roadmap.

Source: Ars Technica

Tags: browsers, Firefox, Mozilla

Add comment

Your name:
Sign in with:
Your comment:

Enter code:

E-mail (not required)
E-mail will not be disclosed to the third party

Last news

Galaxy Note10 really is built around a 6.7-inch display
You may still be able to download your content
Facebook, Messenger and Instagram are all going away
Minimize apps to a floating, always-on-top bubble
Japan Display has been providing LCDs for the iPhone XR, the only LCD model in Apple’s 2018 line-up
The 2001 operating system has reached its lowest share level
The entire TSMC 5nm design infrastructure is available now from TSMC
The smartphone uses a Snapdragon 660 processor running Android 9 Pie
The Samsung Galaxy A5 (2017) Review
The evolution of the successful smartphone, now with a waterproof body and USB Type-C
February 7, 2017 / 2
Samsung Galaxy TabPro S - a tablet with the Windows-keyboard
The first Windows-tablet with the 12-inch display Super AMOLED
June 7, 2016 /
Keyboards for iOS
Ten iOS keyboards review
July 18, 2015 /
Samsung E1200 Mobile Phone Review
A cheap phone with a good screen
March 8, 2015 / 4
Creative Sound Blaster Z sound card review
Good sound for those who are not satisfied with the onboard solution
September 25, 2014 / 2
Samsung Galaxy Gear: Smartwatch at High Price
The first smartwatch from Samsung - almost a smartphone with a small body
December 19, 2013 /

News Archive



Do you use microSD card with your phone?
or leave your own version in comments (16)