Na das sorgt ja vielleicht dafür das FF endlich mal benutzbar wird.

Bisher war's ja so das man bei jedem Update das die Versionsnummer änderte (sei es auch nur in der dritten Nachkommastelle) Zwei Drittel der AddOns in die Tonne treten konnte/musste.

Das wird grandios! Den Browser-Add-Ons darf man getrost eine goldene Zukunft prophezeien. Die perfekte Symbiose aus Web- und App-World.

chill:

Erstens liegt das wohl weniger an Firefox selber und mehr an den jeweiligen Add-On-Autoren, wenn die in die Meta-Angaben ihrer Add-Ons als <em:maxVersion>x.y.z</em:maxVersion> oft nur konservative Punktlandungen machen, statt diese mit Wildcards à la "<em:maxVersion>4.*</em:maxVersion>"auch zu befähigen, in Browser-Updates zu funktionieren.

Denn die Add-On-API von Firefox ist über eine lange Zeit sehr stabil und berechenbar gewesen, erst mit Firefox 4 hat sich da was geändert, aber auch nicht so grundlegend, dass nun jedes Add-On komplett umgeschrieben werden muss. Es gibt viele Add-Ons, die sowohl mit Firefox 3.x funktionieren als auch mit dem derzeitigen Firefox 4.x, und wo man wirklich lediglich diese Meta-Angabe <em:maxVersion></em:maxVersion> in der Add-On-Datei install.rdf nachführen und anpassen muss. Mehr muss teilweise nicht gemacht werden. Und wenn man als Add-On-Autor weiß, dass die API eine gewisse Zeit stabil ist und sich da nix ändert (wie das bisher eigentlich in den großen Major-Versionen des Firefox Browsers immer der Fall gewesen ist), dann kann man als Add-On-Autor auch mal ruhig und guten Gewissens seinem Add-On eine höhere und in die Zukunft gerichtete maxVersion in der Datei install.rdf mitgeben, und dann ist für den Anwender diesbzgl. erstmal Ruhe im Karton. Es ist ja nicht so, dass es keine Add-On-Autoren gäbe, die genau so vorausschauend gedacht und agiert haben, die haben das durchaus genau so gemacht, und deren Add-Ons müssen dann eben nicht bei jedem Browser-Update aktualisiert werden.
Zumal man als Nutzer diesbzgl. da durchaus auch selber Hand anlegen kann, indem man das Add-On hernimmt, entpackt (.xpi-Dateien sind Zip-Archive, die man wie ganz einfach und schnell entpacken kann), in die install.rdf-Datei geht, den Wert für maxVersion auf einen sinnvollen Wert hochsetzt, das Archiv wieder zumacht und nach .xpi umbenennt und das dem Firefox wieder zuführt; fertig ist die Kiste. Ein Aufwand von nur wenigen Minuten. Add-On-Hersteller machen oft nichts anderes, wenn sie ein Update ihres Add-Ons bereitstellen.

Was Anderes ist es natürlich, wenn sich die API des Browsers ändert und/oder das Add-On selber sich ändert, dann ist natürlich ein Update des Add-Ons angeraten oder sogar notwendig. Der Regelfall für alle Add-Ons ist das aber trotzdem nicht.
Es liegt also zum großen Teil auch und gerade an den Autoren der Add-Ons und eher nur zu einem kleineren Teil an Firefox.

Desweiteren gibt es für Firefox seit Jahren ein Add-On namens Nightly Tester Tools (vor allem wohl eher für Entwickler gedacht), welches die Kompatibilitätsprüfung von Firefox bzgl. der Add-Ons ausschaltet, sodass der Browser dann jedes Add-On erstmal akzeptiert ungeachtet dessen ob's tatsächlich dann noch funktioniert oder nicht. Vor allem eben für Entwickler deshalb interessant, weil die eben recht häufig verschiedene in Arbeit befindliche Firefox-Versionen rauf- und runtertesten oder auch für Add-On-Entwickler, die ihre Add-Ons testen wollen.
Außerdem existiert weiteres Add-On namens Add-on Compatibility Reporter das Ähnliches macht und das, wie der Name schon andeutet, vor allem zum Testen von Add-Ons gedacht ist.

Siehe dazu u.a. auch:

Mozilla MDN Docs: Install Manifests
Mozilla MDN Docs: Extension Versioning, Update and Compatibility

Du hast als Nutzer wie auch als Entwickler also gleich mehrere Möglichkeiten, dem, was Du da bemängelst, zu begegnen und das für Dich in einem sehr akzeptablen Rahmen zu halten, solltest Du es ohne diese Möglichkeiten als unzumutbar empfinden.

Mal abgesehen davon: worüber beschwerst Du Dich eigentlich?

Immerhin gibt es da bei Firefox eine offizielle Schnittstelle/API für Add-Ons. Was sollen Safari-Nutzer sagen, die jahrelang ohne eine solche Erweiterungs-API auskommen mussten und jahrelang auf inoffizielle und teilweise krude und sicherheitsgefährdende Hacks (Stichwort: der Weg über InputManagers) angewiesen waren (wohl auch mit ein Grund, warum Apple diesem Treiben dann mit Safari 5 Gott sei Dank ein Ende gesetzt hat und seitdem eine offizielle Erweiterungs-API eingeführt hat), um Safari mit Zusatzfunktionen auszustatten.

Und bei Apples Mail.app gibt es bis heute noch keine offiziell nutzbare API für Erweiterungen. Stattdessen gibt's aber mit jedem Update von Apples Mail.app eine neue UUID, welche die Entwickler von Erweiterungen wissen und in die Meta-Informationen ihrer Erweiterungen einbauen müssen, sonst funktioniert die Erweiterung nicht. Also im Grunde noch viel schlimmer, weil diese UUIDs unvorhersehbare, unplanbare Hashwerte sind, die man als Entwickler erst erfahren kann, wenn die neue Version von Apple Mail.app entweder offiziell draußen ist oder in Entwickler-Kreisen rumgereicht wird. Mittlerweile gibt es glücklicherweise Skripte und Tools, die einem das Auslesen und Schreiben der UUID-Werte in die Plists seiner Erweiterungen erleichtern helfen, wenn man nicht warten will, bis der jeweilige Autor ein Update mit genau diesen neuen UUID-Strings bereithält (auch da sind glücklicherweise einige Entwickler recht fix geworden).

Ich sehe deshalb bzgl. Firefox was in dieser Hinsicht den Browser selber angeht, keinen über das normale Maß hinausragenden Anlass für Beschwerden. Bzgl. der Situation wie das Thema "Erweiterungen" bei anderen Browsern und Software-Herstellern gehandhabt wird, steht Firefox eigentlich ziemlich gut, wenn nicht sogar vorbildlich, da. Allein die schiere Anzahl an möglichen Add-Ons für Firefox (es gibt da inzwischen ja fast nichts was es nicht gibt) scheint das auch zu belegen.