Filter Extension is great, but doesn’t work on last version of Firefox.

Do you works on the new version ?

Regards.

I’ve seen multiple extensions fail because the renamed the extension manager interface! Now of course it may have been done because the interface changed enough they didn’t want old routines calling the new interface with old params… but it seems like it would have been a ‘good idea’, to provide a compatibility routine…

Now to NOT have to maintain um…’N’ compat layers… , you might consider
1) marking an older interface ‘deprecated’, after 2-3 releases (still works, but issues a warning message that you can click on ‘click x to not see this again’, — but the user is warned that that extension isn’t being up updated, and they may have to deal with something.
2) break off shim layers into *extensions*.. i.e. if I’m a user that wants to run
an extension from 1.x, and shimming it into 10.x is costly, put it in an extension and only those who need that will incur the expense. The shim layers would have a list of which modules are using them and only those modules would incur expenses for the ‘shimmed’ functions…
—
The above should give the FF team the freedom to move forward, while providing acceptable alternatives for things they don’t want to include in the new version.

NOTE: Any solution in this area must be in place by the EOLife date for 3.6 (let’s be sensible, that’s where much of the incompat comes from).

Also note — if the FF devs want the freedom to redefine the interface at will, they also need to provide the SHIMS, if they break compat. Personally, I would like to see the Shim group as a separate but blocking entity from the feature group, so the feature group doesn’t feel constrained in thinking about how to implement the shim when they do a new feature, but that _may_ not be practical. But it might if the Shim group — when blocked, gets assistance from the feature group in fixing/implementing the needed shims. There is no requirement that the shim operate with the same speed, but unreasonable degradation should be considered ‘bad’ (I say, unreasonable, as if you move to a HW-based algorithm somewhere, where as the previous stuff, with more flexibility had to use SW, well… there will be a price… )….

But fixing ‘the addon-compat job CAN’T be 1 person’s job, that person needs to be able to ‘block’ release, until the appropriate shim code is written.

Note, in some or ‘many’ cases, nothing needs to be done other than fix the way version numbers are done. It used to be X.Y.Z, X was major changes, Very likely internal interface has changed. Y was for possible changes — but old stuff _should_ work (at most with minimal changes), and ‘Z’, bug fixes, no internal Calling changes.

Going back to a sensible version number scheme would likely help the issue, even if it meant doing a global reset from FF10 -> FFng-4.5, when I saw the version numbers jumping by major numbers every month, I thought, this was really going to kill the basis of FF’s popularity — the extensions — because extension writers can’t be full-time employees writing their extensions; they don’t get paid enough to be that.

————–
Another though — maybe Moz might consider providing a more formal extension source repo — I know they ‘usually’ have a previous versions (is that always the case now?, cuz I remember times in the past when it wasn’t and I had to beg the author for a previous version)…

But it might make it easier for people to fork and submit patches back to a extension maintainer — and if they don’t want them, then just make a fork!…(or a spoon?)…

There has been a bit of a debate over this – I asked someone who thought themes should be compatible by default to post a thread to the dev-apps-firefox mailing list:
https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/HDFiu3mJ3Ws

General consensus there was that themes should not be compatible by default, which matched my original assessment.