Version numbers and add-on breakage
Gerv started a fairly intense discussion about the new rapid release cycle, from the perspective of browser versions and their meaning. As expected, many have replied that the discussion is silly and version numbers are meaningless. This is true for most software developers, and it should be true for most web developers. In software, we have been learning that version numbers have been hijacked by marketing and we shouldn’t pay that much attention to them from the technical perspective. We have branches and revision ids for that anyway. On the web, what should matter are the features the browser offers, not the browser itself or its version. Browser and version detection are frowned upon, and most web devs worth their salt avoid it when possible.
People saying that this discussion is pointless neglect that Firefox is one more thing. It’s a platform, and most add-on developers rely on it. Version numbers matter to add-on developers because the add-on compatibility system relies on application version, not features. And since the features are pretty much every access point in the platform, doing feature detection is not realistic. So, if you’re an add-on developer and you want to keep your add-on up to date, you’ll have to test and increase its compatibility every six weeks, potentially having to make code changes.
On AMO, we have implemented a system where we automatically detect which add-ons are compatible with the latest Aurora version (the version that is between 12 and 6 weeks from release) and then upgrade those that do. All developers for the tested add-ons should get an email explaining their add-on was upgraded, and if not, why. This has been fairly successful, and we have a high compatibility percentage (relative to usage) at the moment (it’s even higher if you ignore the .NET Assistant, which could be compatible now). However, there are still many popular add-ons that aren’t compatible, specially those hosted elsewhere. And the burden on those who develop add-ons with binary components is pretty much constant, because they’ll have to update their add-ons every 6 weeks, with no exception.
So, while only a small percentage of add-on usage consists of add-ons that are incompatible (hovering something between 10% and 20%, I think), the probability that one of our add-on users has at least one incompatible add-on is even higher. And having to roll the dice every 6 weeks and see if your add-ons are compatible or not puts a great deal of stress and dissatisfaction on users. And like Colin Coghill comments in Gerv’s post:
If add-ons break randomly every few weeks, effectively FF no longer has add-ons.
Version numbers have a real impact on our users then, and they should be taken very seriously. Now, would the previous releases have worked as minor version increases? I think so, yes. The breaking compatibility changes have been fairly minor so far, with the exception of binary add-ons. Even if we hadn’t done any communication about it, I’m fairly sure that the problems would have gone mostly unnoticed, by both developers and users. Of course, that’s only because so far the changes have been minor. This shouldn’t be the case for every release, and that’s a big concern. For example, Firefox 7 will remove a couple of JSON parser functions that are heavily used by add-on developers. We’ll see how that goes.
So, what are the alternatives? There are a number of proposals, with their own advantages and limitations. I personally think that going back to the initial idea or 3 month-long tracks (instead of 6 weeks) would be a major improvement. Nils Maier (author of DownThemAll!) has a very detailed proposal in the comments on Gerv’s blog (unfortunately, I can’t link to the comment directly), which consists of having planned minor and major releases, where major releases happen only twice a year. I like that one as well.
As usual, I expected this be a short post and then it grew into a monster. Oh well. I’ll close by saying that we’re working on a number of ideas to make this release cycle as smooth and stress-free as possible to add-on developers. Most releases will change nothing you care about, so you shouldn’t need to worry about it. I strongly recommend all of you to track the Add-ons Blog, which is becoming an increasingly important source for updates. I also recommend that you give the Add-on SDK a shot. If your add-on can be implemented using the SDK, it’s better for you that it is.
for its contents. This is a safe-cache copy of the original web site.
Forgive my slightly off-topic naivety but wasn’t the justification for bug 645922 that “these methods have no users”… yet you’re saying they “are heavily used by add-on developers”? It strikes me that one party or the other is working on a flawed assumption.. and if it’s Jeff then should that patch really be happening at all?
Jorge,
This goes back to a discussion we had a long time ago that basically Firefox developers are pretty much oblivious to the needs of add-on developers.
Add-on developers believe they are an important part of the Firefox ecosystem.
Firefox developers believe it is all about the web developers.
The icon fiasco was a classic example of this.
As long as there is this rift between Firefox developers and add-on developers, the problem will never be solved. And over time you’ll see more and more add-on developers stop developing for Firefox.
And I’m sorry, but using the Add-on SDK is simply not an option. As has been pointed out repeatedly, most add-on developers do this in their spare time and the idea of investing a ton of effort to port it to a new platform where there is a high likelihood it won’t work (despite what fligtar says) is simply not worth it.
Well, if their choices boil down to abandoning add-on development altogether or trying a different platform, I think it’s worth the try. The SDK won’t work for everyone, but it will work for some. The majority, I would even dare to say.
Have you tried to port fire.fm to the Add-on SDK?
No, I’m sure it’s impossible. Same goes for BT, as far as I know. But the bulk of add-ons listed on AMO are extremly simple and could be ported with not that much effort.
> But the bulk of add-ons listed on AMO are extremly simple and could be ported with not that much effort.
You guys keep saying that.
How many add-ons have been ported to the Add-on SDK? How many add-on developers are willing to build add-ons that only work in Firefox 5 and beyond?
I’m basing that statement on my knowledge of the add-ons I review every day and my knowledge of what’s available in the SDK. It has nothing to do with what developers have done so far or what they are willing to do. And I think they will be willing to give the SDK a try if that solves their constant upgrade problems. Whether they do it or not remains to seen.
As for backward compatibility, most developers are happy to drop old versions if necessary. That’s also a fact.
> As for backward compatibility, most developers are happy to drop old versions if necessary. That’s also a fact.
I would strongly dispute that. Firefox 3.6 still has a huge market share. Do you really see major add-ons wanting to drop that platform?
3.6 was replaced by 4 only a few months ago. Those developers that supported 3.6 and could make the switch to 4 without breaking backward compatibility will of course maintain it. Many others preferred to support only 4 in new version because it was much easier that way. New developers won’t even bother with 3.6. I’m referring to the majority of developers who are relatively casual. More business-oriented types wouldn’t want to ignore the lingering percentages in 3.6.
Regardless, if a developer has an add-on that currently supports 3.6, 4, 5 or any combination thereof shouldn’t have to worry about migrating to a platform that only supports the most recent versions of Firefox, since there’s already versions of the add-on working on older versions of the application. And new developers (again, the casual types) wouldn’t worry about anything older than 4, where SDK add-ons work anyway. So I don’t see how backward compatibility is a concern for the majority of add-on developers.
I don’t think that many are worried about backwards compatibility either. They’re more concerned about what’s ahead every 6 weeks.
You can’t deny that a good chunk of add-on developers, long time ones and that contributes to the Mozilla project in other ways are going to just fade way. It already began with 4.0.
I’m sorry to say it, but I really believe that Mozilla doesn’t have a problem with that. Either keep up, or drop out.
The choices for add-ons are going to be limited.
That’s already happened with Themes.
The big dogs will of course still be around, but the fun, niche, creative, and unique ones just won’t be.
I see more search plugins being uploaded than any other thing right now, and it’s been that way since 4.0.
Sure, eventually, more and more people will start using the Add-on Builder and SDK, but there’s gone to be a gap where choices are limited, and Firefox really can’t afford a gap. Mozilla can’t.
Add-ons are the edge that Firefox has. Everyone knows that. I read more comments on blogs and news articles than I do the articles itself, and time and time again, it’s add-ons or a particular one that is retaining users.
I know that you and others have given ample notice and posts on the topic of restartless add-ons, but perhaps there should have been a greater push to get people on board and educated, and enough time to provide a substantial amount of demos and documentation before the major marketing push to use the Add-ons Builder and SDK.
But, then there wouldn’t have been a way to keep up with the rapid release cycle.
I understand it’s a tough balancing act, but I just don’t see enough love and respect for add-on developers.
I don’t mean from AMO, you all do great work, you keep people informed, and things run pretty damn smoothly, but the picture isn’t about add-ons, it shouldn’t be, but it should be a major part of the discussion.
Why? Because the end users want add-ons. There are other choices in browsers today but they just can’t compete with Firefox’s customization abilities and options.
Jorge, I have a question:
is the tool used to automatically check the compatibility of extensions on AMO available outside AMO?
A lot of companies do not want to use AMO (e.g. for internal extensions that don’t need to be distributed to the whole world). They would be happy to use internally the checking tool to find problems far ahead in the process, without relying on code inspection and testing.
This would help them (but do not solve all problems).
The whole thing with fast releases, a stable Add-on API and other things is that Firefox wants to be competitive in the browser market. Fighting by the rules of the enemy though, does only lose you the war, not win it. Chrome sucks at extensions (or changeability/extensibility in general) and that’s why THIS is the grounds it needs to be attacked on. Browser speed and cleaning up the UI is important, sure, but it’s not going to win you this battle by itself.
Firefox can be extended in so many ways while Chrome doesn’t provide the means to do that. If you strip this ability from Firefox, you’ll get a browser with the limitations of Chrome and not even its speed (this might be to be debated but it seems the prevailing opinion out there).
That’s why I think that add-ons should become more awesome, not more limited. Having them restartless is a good start and once they can use chrome (internally), things will even get easier for developers. The Add-on SDK might be a good idea for small and easy things but if it can offer a replacement for fully fledged add-ons one day remains to be seen.
Orphaned add-ons on AMO can be an obstacle to updates, that’s clear but maybe there are things that can be done about this as well: what about allowing to officially fork extensions and notify users if a different fork is compatible with a new version of Firefox while the original extension isn’t? Or to notify them of similiar extensions (however “similiar” would be decided) that are compatible?
Some more ideas about awesomeness in general: what happened with the idea to revamp the interface so it’s suited best for the website you’re currently using? (I saw a mockup with a Twitter-button next to the Firefox button coming though PMO one day but I can’t find it at the moment). That’s along the lines that I started with: hit Chrome where it hurts them most. Customizing the browser is possible for you, not them.
Now go and DFTBA
Might I suggest that if you have a two-tier system (hashcash or Akismet for those who don’t needlessly use JS) you check the Akismet bin once in a while?
Would it not be possible to test addons with binary components for compatibility as well and automatically upgrade them?
It should be possible to use a linker script to dump the mozilla entry-points used by the binary components, and if none of those entry points (and their associated types) have changed, then the addon should still be compatible.
It’s a fair amount of work, but it would dramatically lower the burden on add-on developers.
@Danny Moules: sorry for that! I don’t use this blog much. Regarding bug 645922, I believe the comment just refers to users within the Mozilla code. They evidently forgot that add-on developers are users, too. However, I did get a heads up from one of the Firefox devs when this change happened, well in advance. We are discussing now if such changes should really happen this way or if there should be a deprecation path. Maybe this change will be reverted, but for the moment I’ll assume it’s final.
@teoli: Our code validator is open source, and it can work as a standalone tool: https://github.com/mozilla/amo-validator/. It should include all the compatibility checks up to Firefox 6. The Firefox 7 checks should be implemented very soon. If you like, I can also give you the bug list for Firefox 7, so you know which patterns to look for. I’ll blog about this soon in the add-ons blog anyway.
@Benedikt P: I agree 200% with your first 3 paragraphs. In regards to forking, most add-ons are not open-source, so that’s a problem. It’s not hard to create an equivalent to most existing add-ons, but copying without respecting copyright is not allowed. Similar extensions is doable, but difficult. We have categories that should indicate which add-ons do roughly similar things, but knowing which ones are equivalent would probably work best as crowd-sourced data.
@Noel Grandin: it’s not that easy. In fact, there’s a new validation that is included to ensure that the component is built against the specific SDK that ships with Firefox. It’s possible to create a system where components are recompiled for each platform, but the build systems for each developer is wildly different, and any bugs in the system would probably lead to crashes, which is much worse than the cure. It is a good idea, though.
For binary add-ons, this means “recompile every six weeks, even if the functions you call haven’t changed, because you must know the exact XPCOM version in advance”. This is of course a non-starter, except for a very extremely small number of extensions: those whose source is on a mozilla.org Mercurial repository and which are recompiled once a night or more by buildbots. Lightning is one example (and it includes a binary XPCOM component). ChatZilla doesn’t need it because it is js, XUL and images only. DOM Inspector and Venkman I don’t know. I think that’s about all: an exxtremely short list, as anyone can see.
Add-ons with binary components are a very small minority anyway, but they tend to have significant usage because they are built by large development groups and are meant to be more commercial. I can see how having to download the new SDK and rebuild every 6 weeks can be a pain for most devs, specially if they need to build for different platforms, but I wouldn’t go as far as saying that only projects close to Mozilla can pull this off. There are several developers we talk to frequently about this, and they are keeping up. For how long, I don’t know.
About the Add-on SDK: don’t forget that it is Firefox-only. Building Jetpacks instead of «legacy» extensions (yes, it has been said, _both_ that “traditional” extensions would never be abandoned _and_ that at some future time they would be deprecated in favour of Jetpacks) — building Jetpacks leaves SeaMonkey and Thunderbird users out of the game. Now I’m neither a browser developer nor an extension developer, I’m a user (who does some QA on the side from time to time), and what attracted me (in sequence to Netscape 6, Firefox, Thunderbird and SeaMonkey were the extensions and themes. If all themes other than Personas (for all apps), and all extensions (for all apps) other than Jetpacks for Firefox only, disappear, I’ll be going in search of a different browser and mailer. Opera? Chrome? Konqueror? I don’t know yet.
For how long, I don’t know. Exactly. Wladimir Palant (a well-known author of popular extensions) recently said in a different blog that binary extensions have become a non-starter, and I agree with his reasoning.
P.S. to comment 18: SeaMonkey can use some restartless addons, but not Jetpacks, and there are a few of those — extremely few, and they never do much, though I have found two of them useful (vs. thirty or so “traditional” extensions).
Re: binary components
My mintrayr has well beyond 100k users and is developed by the one-man show that is me.
I need to build for 4 ABIs x # of versjons. Not fun. And with ctypes jt does’nt really look any better because I hit limitation or bug after another :p
Re: Simple addons
Most simple addons are usually also the unpopular ones. The majority of the real popular addons cannot be ported to to the SDK. Even the current SDK addons often have a require(“chrome”) somewhere and hence have the same breakage problems as regular addons.
The current state of afairs is pityful at best.
Year after year I heard the promises that things will get better, but always things just worse.
Danny, there are two issues in play in the bug: the JS_TryJSON method that was part of the JSAPI, and the nsIJSON.encode/decode methods. I referred to the former when making that comment. It so happened that the latter two methods were one of the few users of JS_TryJSON. (I was mistaken when I said “no users”, as you can see from the patch landed not being the patch associated with that comment.) Rather than spend time writing code to change them to not use JS_TryJSON, it seemed better to just remove them given that they’re strictly less powerful than JSON.parse/stringify and totally not standard at all — unlike JSON.parse and JSON.stringify. Who’d want to use random Mozilla-specific APIs when you could just write code like you would for any website? (I’d go a step further and say we shouldn’t have Mozilla-specific APIs duplicating standard ones, sowing confusion in the process — hence removing the old gunk from nsIJSON.)
As far as Jorge’s comment 15, I did not forget that nsIJSON.encode/decode are used by extensions. Again, the comment you’re seizing upon referred to JS_TryJSON’s users, not to nsIJSON.encode/decode users. I’m completely aware that nsIJSON can be and is used by extension developers. I simply believe that it’s fairly simple for extension developers to update their extensions to use the JSON methods (which have been in Firefox since 3.5 or something similarly ancient), and that there’s plenty of time before Firefox 7 for them to make those changes. And for what it’s worth, I was the developer who gave Jorge and Justin the heads-up noted in that comment, because I was aware that modifying nsIJSON would affect extensions.
I think it would be interesting to go down the list of extensions at AMO sorted by number of users, if it could be ascertained for each of them whether it is:
- non-Jetpack restartless (best for multi-app compatibility)
- Jetpack
- “classical” with only JS, XUL, etc. (probably a very high majority)
- with binary components.
FWIW, I see one binary extension listed as #5 by number of users for Thunderbird and #10 for SeaMonkey, and I know for a fact that its developer doesn’t have as many time as would be needed to see to all the issues.