Taking a conservative approach to compatibility reporting is the right way to do things when you have a sane versioning policy and upgrade cycle. This gives extension developers time to test compatibility before declaring compatibility, and perhaps to fix problems. When your upgrade cycle is something like six or eight weeks long, with major version numbers incremented during that time, the upgrade cycle could easily pass by without the developer having time to even notice, and there is no reasonable way to provide development versions sufficiently close to the final release version to make compatibility testing possible in any meaningful way. What this means is that extension developers are then forced to make a choice between just claiming compatibility while crossing their fingers, and letting extensions break until the developers get a chance to test on the release version.
Of course, if there is some kind of compatibility issue discovered in testing, it is even possible that what may have been fixable before (or perhaps shortly after) release under a sane versioning policy and upgrade cycle to take more time to fix than the entire upgrade cycle. For especially sophisticated extensions, the end result might be that the developer eventually gives up and just abandons development. Isn't that wonderful?
Where a conservative approach to compatibility reporting is the right approach for a sane versioning policy and upgrade cycle, there essentially is no right approach for the kind of insane versioning policy and upgrade cycle used under the new Firefox development schedule at Mozilla. For conservative compatibility reporting, you get the ill effects described above, which is obviously far short of a good idea. The other end of the spectrum -- a liberal approach to compatibility reporting, where things are generally assumed to work unless users say "Uh, this is broken!" -- results in a lot of broken extensions on upgrade. Sure, fewer are *reported* as broken, and the reality is probably that no more of them are *actually* incompatible than usual, but those that are really incompatible will tend more often to get to end users with a "compatible" label then fail to work properly. This may result in truly disastrous effects, such as wiping out saved data, breaking basic operation of the browser without any easy way to undo the damage, and otherwise making life quite difficult for users from time to time.
I suppose the Mozilla guys could suddenly decide to start doing something they have been pretty bad at doing all along; keeping APIs stable, with compatibility shims provided even for cases APIs do change (with an announced deprecation schedule to give extension developers a well-ordered way to get their extensions up to speed). With the adoption of Mozilla's newly nutso versioning policy and upgrade cycle, however, what has been done in practice is to just give up entirely on any thin veneer at all of caring about stable APIs for extension developers, going in the opposite direction from this possible solution to the problem. As such, I will not hold my breath that things will get better. Instead, these asinine "we're all about the developers (but really we figure they're unimportant and need to serve us rather than the other way around)" policies will probably continue to get worse as time goes on.
There might be a glimmer of hope, in the advent of this new extended support release idea. I fully expect that it will turn out to be nothing but the gleam of candlelight off the edge of one of the knives Mozilla plans to use to inflict greater agonies on both users and developers, however. The glimmer of hope is that it looks like Mozilla might be suddenly coming to the conclusion that differentiating between major releases, minor releases, patch releases, and the occasional nightly build that does not appear to be buggy (though I don't know how you can tell it's not buggy when you just fire it up a few times and it works for you at least). It almost looks like Mozilla is planning to treat v10 like a v1.0, with the tens digit as the new major version number and the ones digit as the new minor version number. I imagine the first decimal place will then essentially become the new patch release number. I doubt things will work out that smoothly, though. It seems more likely that the extended support versions will be like those of the Ubuntu project -- arbitrary choices of releases that will just be supported longer at a given major version number, but not particularly differentiated from any other major version number release apart from that extended support period.
The biggest problem with all of this, of course, is a combination of stability issues that come from insufficient testing before release, versioning policy incompatible with OS release cycles so that relatively recent installs of various OSes will quickly end up with utterly obsolete and unsupported Firefox versions (perhaps partially solved by the extended support releases), and an extension system prone to breakage -- that is, even more prone to breakage than it was before. Given the tremendous surge of competition at the forefront of the renewed browser wars, with quite a few additional browsers achieving quite interesting advances in the state of the art, it is surprising that no other browser has duplicated the flexibility and power of the Firefox extension system yet (as far as I've seen) apart from the uzble browser. Of course, uzbl's extension system is incredibly difficult to use, and uzbl's licensing makes extension development seem a bit unpalatable to many developers, so the power and flexibility of its extension system is somewhat undermined, still leaving Firefox at the top of the heap where extension systems are concerned.
With the recent moves in Firefox development schedules, however, the killer feature of Firefox (its extension system) is also being drastically undermined. As long as no other browsers offered quite the same set of features that I have come to expect out of my primary browser choice, and had gotten from extensions for Firefox, Mozilla's flagship application has been inescapable for me. I have not been able to give it up entirely in favor of any other browser, or even to relegate it to the position of a second-class citizen with some other browser becoming my primary choice, between when it was called Phoenix (before the name changed to Firebird, which was also before the name changed again to Firefox). I have long noted the fact that Firefox quality has degraded steadily since late 2004, when it was released under the new name Firefox as a 1.0 release version, but in all this time and all these experiments with literally dozens of other browsers, I had not found a suitable replacement for Firefox.
In late 2011, then, I stumbled across a relatively new browser project called xxxterm. I started playing around with it. Like learning to use vi, it started with a relatively steep learning curve, and (also like learning to use vi with the way it demands a different manner of thinking about text editing) making the best use of xxxterm required changing the way I thought about how I browse the web. Like learning to use vi, this has turned out to be very much worth it, as the benefits outweight the detriments by orders of magnitude so far. In January 2012, I discovered that I simply had no desire to use anything Firefox provided with the exception of a couple minor features that were not enough to make me put up with the rest of its brokenness. Basically, the only times I opened Firefox in January were those times when I needed to move saved tabs and bookmarks from Firefox to xxxterm. I have not had to do that for a couple weeks or so, and now I fully expect that I will not need to open Firefox at all in February, unless it is just to make sure there isn't anything else I need before uninstalling it.
Sorry, Firefox. You blew it. You lose a user and, if they're at all smart, you're going to lose quite a few more. (So did Chromium, aka Google Chrome, when it failed to provide a non-amputee extension system.)
