Firefox 7 dropped yesterday.
So now I have seven profiles to test the last seven versions of Firefox that my users could be using: 3.0, 3.5, 3.6, 4.0, 5.0, 6.0, and now 7.0. And this doesn’t count the dot releases for each major version.
This is a major pain when issues arise, since users could be using any of those versions. To recreate buggy behavior, you really need the same browser (and version) as the user.
Realistically, looking at Connect’s analytics, I don’t see any 3.0 or 7.0 visits, but there is a pretty even mix of the other five versions. Looking at the analytics for this blog, I see a similar mix, that now includes 7.0.
This is extremely messy. I guess it’s slightly better than the four instances of IE (6, 7, 8, 9) that I somehow have to test on separate instances of Windows.
Chrome, on the other hand, does two things differently that help with testing. First, by dividing the browsers into channels (released, beta, development, Canary), users know what they’re using and how flaky and experimental it is. Because this is known by the user at install, the web developer can fairly refuse to support non-released versions of the browser.
Second, Chrome updates automatically, keeping the channel you’re using at the latest version.
While Firefox does alert the user to updates, they require user intervention to accept, and the user isn’t forced to bump up to a newer release. So, you get a wide distribution of Firefox versions.
And given the recent issues Mozilla has had with its rapid release cycles and enterprises, it’s unlikely that you can drop support for older versions and tell the user to upgrade.
So, thanks to the new browser wars, web development potentially requires seven Firefox profiles, four IE installs and at least one Chrome version. That’s 12 different permutations per OS.
Yikes.
