posted by steve | Category: Random Rants |

After participating in a Slashdot thread about Mozila End-of-Lifing Firefox 4 already (just a few months after it came out), and then thinking about a discussion a few months back about WHATWG ditching version numbers for the HTML specification, I got to thinking more about version numbers and why they matter.

Version numbers (or even names), such as HTML5, Firefox 3.6, Windows 7, Mac OS X Lion, and iOS 5, matter.  They indicate a point in time and provide a reference to the featureset supported.  For example, mention Internet Explorer 6 to any web developer and they may cringe.  IE6 is as notorious for its lack of standards compatibility as it is for its longevity.  When a developer knows that he or she must support IE6, they automatically know that they can’t support many of the features available in newer versions and also have to provide workarounds for several bugs and anomalies inherent in IE6.

Previously, Firefox released major versions when there were major changes to the browser.  So a change from Firefox 2 to 3 brought major interface and UI changes.  Following along that model, when there were minor tweaks to the UI or the underlying web standards supported, Firefox might release a minor version, such as 3.1, 3.5, or 3.6.  Finally, when there was a bug or security fix, it was bundled into a point release such as 3.6.1.

This model worked quite well for years and helped Firefox to gain significant market share.  Several years ago, corporate web sites didn’t support Firefox, meaning that the site either wouldn’t render properly or wouldn’t work at all in Firefox.  With the increased market share came increased corporate support for Firefox.  No longer could a business turn away 10% or 20% of its visitors simply due to their browser.

Along came Chrome which began making version numbers irrelevant.  Google releases Chrome versions much more rapidly than Firefox, currently on version 12.  However, unlike Firefox, Chrome does not have the widespread adoption rate and thus the widespread explicit support from major corporations.  Granted, sites work well in Chrome but try calling your bank’s tech support line and telling them that you’re having a problem with their site using Chrome.  You’ll be told to get a supported browser.

Somewhere along the way, Firefox decided that it needed to compete with Chrome and to do so it needed to not only decrease its time between releases but also increase its major version numbers.  Decreasing the time between releases makes sense; keep adding new features and improving speed and support for web standards.  Incrementing the major version number does not make sense every six weeks.

When designing a web site, organizations need to determine what browsers will be supported.  What experience will the visitor have in a particular browser and what will happen if they visit using an older browser?   This means making choices about what browsers to support and then what features can be used based on the requirements for support.

Somewhere, right now, an IT architect or developer is talking to his manager indicating that they now need to support Firefox 5 because Firefox 4 is out of date.  And Firefox 6 is coming in 6 weeks.  Businesses, with limited resources, need to test their sites in these new versions in order to keep claiming support for them.  Sooner or later, businesses won’t be able to keep up with this rapid release cycle and will have to make a choice to either stop supporting Firefox or keep devoting resources to testing in the browser.

Granted, not much changed between versions 4 and 5 of Firefox.  But at some point, something major *will* change between versions.  Previously, it was easy to tell if something major was changing because the major version number changed.  Without being able to use the major version as an indicator of change, IT departments will need to  test the sites in each version, read release notes, and otherwise spend time that they shouldn’t need to spend.

Users are also hurt because add-ons with Firefox can and do break between major version numbers or at least aren’t listed as being compatible between the new versions.  So now users are left to either run potentially incompatible add-ons or not run the add-on at all.  This doesn’t even take into account the add-on author’s time testing the compatibility.

Version numbers simply matter.  They let us know what to expect when choosing to spend resources to support the technology, when programming for the technology, and when using the technology.

Tags: feature