If you have been following the recent Firefox releases, you are probably already aware that Mozilla is now following a rapid release cyclefor Firefox. Frustrated by the innumerable delays that plagued the release of Firefox 4, Mozilla decided to take a leaf out of Google’s book, and release a new version of Firefox every six weeks. Unfortunately, the new quick-fire release policy creates some major issues that Mozilla doesn’t seem to be willing to tackle.
The first problem is that it makes version numbers redundant. A major version number bump normally indicates the introduction of major new features along with significant enhancements to existing features. However, the biggest new feature in Firefox 6 domain highlighting in the address bar, is something that wouldn’t excite even the most passionate Firefox user. Firefox 5 was even worse.
The biggest feature in Firefox 5 is that the Do Not Trackfeature, which we have discussed in a fair amount of detail in the past, is now more accessible. It is now available under the Privacytab, instead of being buried under Advancedoptions. Yep, the biggest user-perceivable change in Firefox 5 is a minor interface tweak.
Of course, this alone isn’t such a big problem. Undoubtedly, it’s annoying and stupid. However, Firefox’s auto-update does a good job at making the update process hassle free. Add-on compatibility was another issue that I was worried about. However, Mozilla seems to be doing something right in this area. All the add-ons I used were compatible with Firefox 6 at launch. At the time of writing, 99% of the top extensions, which constitute 95% of the total extension usage, are compatible with Firefox 6.
Unfortunately, there is one issue that Mozilla doesn’t seem to have a solution for. The rapid fire update policy means that every year we will be witnessing eight to nine major version trunks of Mozilla. However, Mozilla isn’t willing to support the older version trunks. If you are on version 4, which was released just a few months back, then tough luck. Mozilla won’t be providing any further updates to the 4.x trunk. Updating to newer versions might not be a big issue for home users, but it is a major undertaking for enterprises. Each major update has to be tested for regressions and other issues before it can be deployed. Mozilla’s reluctance to support older trunks mean that enterprises stand the risk of being left vulnerable to serious security vulnerabilities over extended periods.
Enterprises are notorious for their reluctance to switch to newer and better browsers. It’s only recently that some of them have begun to opt for Firefox. However, with the new rapid release cycle, Mozilla will almost certain succeed in making all of them revert to Microsoft Internet Explorer, since Google Chrome also follows the same quick-fire release cycle and Opera has too many website compatibility problems (often due to factors out of its control) to be considered seriously. In contrast to Mozilla, Microsoft will be supporting Internet Explorer 9 till January 2020.
So why is Mozilla using the rapid release cycle? It seems to offer very little benefit and is misleading, annoying, and counterproductive. This is what Asa Dotzler, product manager for Firefox, had to say:
I can give you an example that may help illustrate the value in faster release cycles. In June of 2010, Mozilla engineers added WebM support to Firefox’s HTML5 >video< tag. But users and the Web and Web developers did not see that in a shipping version of Firefox for more than 9 months when Firefox 4 finally shipped.
That delay was bad for the Web and bad for the users. When you only ship a feature when all other features scheduled for a release are complete, your schedule can grow, in the case of Firefox, to a year or two.
We’ve moved to a new cadence that allows us to ship a feature when it’s ready, even if dozens of other important features aren’t yet complete.
Dotzler certainly makes a very valid point. It’s better to push through a major new feature like WebM as soon as it is ready, rather than waiting for all of the other new features to be ready. However, Firefox’s current release cycle can’t really be called feature driven. Both Firefox 5 and Firefox 6 didn’t contain any feature that needed to be pushed through as soon as possible.
Mozilla is aware that their new rapid release system breaks the established version numbering system. Unfortunately, the solution that Mozilla is considering implementing is rather insincere. Mozilla will be dropping the version number information from the Help –> About dialogue box, where almost all applications are typically expected to house the version and build information. Here’s Dotzler’s Bugzilla submission on the impending change.
When a user opens the About window for Firefox, the window should say something like “Firefox checked for updates 20 minutes ago, you are running the latest release.”
It is important to say when the last check happened and ideally to do the check when the dialog is launched so that time is very near and to drop the version and simply tell them they’re on the latest or not.
If a user needs the full version information they can get it from about:support.
In Mozilla’s bizzaro world, the best way to solve a problem seems to be by brushing the symptoms under the carpet rather than dealing with the root cause of the problem. Dave Garret explained the folly of hiding version numbers from the “About” dialogue box succinctly.
The about dialog is essentially a box designed for the sole purpose of housing the application developer and version. I am sorry to break it to you, though, even if having the version in the about dialog is a UX problem in any way, virtually all other applications out there beg to differ. Even my mother knows this is where you look up what version of a program you’re using. You’re going up against established UX that spans much time and across OSes.
The greater point here is that any gain that could be made trying to hide the version is not worth the expected confusion of people no (sic) being able to find it in the same place every other application has it, and not worth the eventual flame storm this will create.
Mozilla’s problem is not that its version number is soon going to be insanely high. Its problem is that it is confusing users by labeling minor releases as major ones, and it is alienating enterprise users by refusing to provide long term support. If delivering features is the ultimate aim of the faster release cycle, then the release cycle needs to be flexible enough to be determined by the completion of new features rather than being strictly time bound. At the very least, there is no reason why they can’t have four minor releases and two major releases per year, instead of the current eight to nine annual major releases. If Mozilla wants to address the real problem then they will have to get the balance between release speed and features right.