Just saw a post that Firefox 7 was released today as part of the “rapid release” strategy and I thought it was worth a few minutes to type a little blog for this.
Firefox has basically adopted 2 things here. One is the Google-sque version numbering convention for just updating it quickly for no apparent reason other than there is a new sprint, the other is what essentially amounts to the agile software development cycle.
Realistically Firefox can call their browser what ever they want and give it what ever number they want…3.0, 3.5, 3.6, 4.0, etc, etc, etc. However what people are basically losing sight of is what that number means to people. As somebody in the industry when I see a major or minor version number change like the ones above, I am trained to expect is problems. It means that somewhere in the system someone has made a change that might or might not affect my application. This is where the Firefox strategy starts to fall down badly. Arguably the changes are minor that are happening, but as this post explains “we might break something” so you need to test. As a corporation running internal types of tooling, this just doesn’t work. I have no real need to be updating everything every 6 weeks and retesting so that I ensure that everyone of my 100+ applications still work with the new version. In reality, 99% of them will be fine, but that 1% creates havoc since now I can’t update the browser, which might mean I can’t update the OS and invariably at some point I will get a newer application that won’t work on the old version…havoc ensues.
What the browser companies need to do a much better job of is what MS actually does a pretty good job of and that is backwards compatibility. It is fine to do releases every 6 weeks, it is fine to add features to those releases, but you need to achieve the goal of giving people a stable platform that won’t necessarily break every time you turn around.
http://mike.kaply.com/2011/06/21/firefox-rapid-release-process/