AdSense Top


Firefox and the Enterprise Environment

Firefox recently updated to version 5, and sent Firefox 4 to the EOL graveyard.  It plans to do the same with Firefox 6 in 6 weeks, and Firefox 7 6 weeks after that.  Enterprise IT staff are in a tizzy because their internal testing takes that long to figure out whether a piece of software will work for them, and the rapid release schedule completely destroys their system for testing.  See this quote from Mike Kaply's blog by John Walicki to get the idea.
I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications. Many hundreds of application owners and their test teams have participated. We gave them several months to ready themselves. We worked with dozens of internal Add-On developers and product teams to prepare their add-ons for Firefox 4. We’re poised to deploy Firefox 4.01 in 3Q when the corporate change freeze lifts. Education programs, documentation updates, communications all are planned. While several of us keep up with Aurora, I can’t expect thousands of app owners to do the same. I applaud the effort to accelerate the pace of Web experience and I expect to chase version releases well into the future. The Firefox 4 EOL is a kick in the stomach. I’m now in the terrible position of choosing to deploy a Firefox 4 release with potentially unpatched vulnerabilities, reset the test cycle for thousands of internal apps to validate Firefox 5 or stay on a patched Firefox 3.6.x. By the time I validate Firefox 5, what guarantee would I have that Firefox 5 won’t go EOL when Firefox 6 is released?

Asa Doltzer responded that he would do the opposite and guarantee that when Firefox 6 is released, 5 will go EOL.

I understand John's (John works for IBM in their IT department) concerns with regards to internal testing and the test version they used being no longer supported by the time they roll it out.  I just think there's an easier solution than trying to force Mozilla back to their earlier versioning scheme. Currently Mozilla puts out 3 to 4 branches for public use. These are:

Full Release: The standard releases you're all familiar with. The most stable release. Currently on version 5.

Beta: A familiar name for a familiar concept.  Pulled from the Aurora branch shortly before being pushed out as the next Full Release.  Currently not available.

Aurora: The perpetual beta branch.  Aurora is pulled from Mozilla Central and is where UX and new feature work takes place.  If something isn't ready that's in Aurora when Beta is set to be branched, it gets disabled and pushed back to the next release. Not the most stable, but not the least.  Currently on version 6.

Mozilla Central (Nightly): Mozilla Central is the trunk of the Firefox dev tree.  Most work gets done on Moz Central, and every night the first build to pass their automated test suite is pushed out as the Nightly release.  Inherently the least stable.  Currently version 7.

Based on this information, my advice to enterprise level IT staff:  Start testing Firefox Aurora, and follow it through until it hits Full Release.  Yes, there will be some changes to Aurora while you're testing it, but all those changes are publicly available on bugzilla, and are fairly easy to collate into a single list for you to keep an eye on.  Watch for changes that have an effect on you or your tests, so that you can time your rollout of Firefox with when it hits Full Release.


  1. "Based on this information, my advice to enterprise level IT staff: Start testing Firefox Aurora, and follow it through until it hits Full Release."

    Yes - some in-house apps could be tested like this but what about the 3rd party apps that require support contracts (and therefore stipulations re supported browsers/platforms)? I can't see many vendors supporting Firefox in future due to the testing effort involved. They're only going to test significant browser versions.

  2. The heart of the matter is that Mozilla's versioning scheme doesn't follow the traditional methods anymore, so traditional testing and support rules won't deal with it properly. I agree that it will certainly drive vendors away from supporting Firefox (for now at least), but I do like that they're trying to change the versioning paradigm (even though Google has been at this game longer with how Chrome takes updates).