We need to admit that, in practice, there is a tradeoff between security and stability. A tradeoff between aggressively preventing extensions from breaking the browser and encouraging user’s to get security fixes.

Any arguments should keep this in mind. Statements like “I do believe, though, that breaking the browser for some non-techie people, just because probability of that is low (even if it’s in fact low), is wrong.” fail to address the security concern. I’d say it’s worse to encourage people to stay on old version without security fixes (High likelihood: happens all the time) than to allow breaking the browser (this level of incompatibility happens much less often).

http://www.mozilla.org/projects/firefox/extensions/update.html says “In most cases, this pref will stay the same between minor versions.” Notice the “in most cases”. So it’s not maxVersion’s design/implementation problem that the a.e.v wasn’t bumped for 1.0.3. It’s a conscious decision of whoever is in charge of Firefox, preferring “state 1″ for extensions that used window.__proto__ trick over “state 0″ for all extensions in a minor upgrade.

In Wolf’s comment “major milestone” was just an opposite for “nightly builds”.

* re “by the time the milestone is released, compatibility is Known, not Unknown”. If that’s the case, why would you need to remove the maxVersion, if the “community” updates compatibility information for all extensions by the time of release?

* re “relying on just the community”. I am well aware of the role of Mozilla community. But do you think there would be any Firefox success if QA or coding was left to the community? Why does MoFo has dedicated QAs (Asa/Sarah/Marcia/Tracy) then?

As for what makes me think that the fact that there is someone in charge of X means it’ll get done, – it doesn’t. It’s just that (1) it’s more likely to be done and (2) as things are now, we don’t break users (users’ application, to be precise) if a person in charge doesn’t do anything by the release.

* re “uninstalling Adblock 0.5″. I believe that’s partially your (adblock devs’) responsibility. Although that doesn’t have anythinng to do with “maxVersion protection”. In fact you sabotage it by setting maxVersion to 10.0 in your update.rdf.

* re “bumping maxVersion in UMO’s database”. What you say is simply not true. There is a database at u.m.o which is used to generate equivalent of update.rdf for extensions that don’t orovide updateURL in their install manifests (that’s what called w@u in the bug, although it’s not really a webservice). Granted, this doesn’t work perfectly for users without permanent access to the Internet, but implementing your suggestion would simply break them anyway.

I don’t see why it’s too late to do something right. The problem is, it’s not clear what solution is better than what we have now. At this moment, I think that it’s important to implement Jesse’s #1 (like the mails which have been sent to authors that have an account at UMO with 1.0.3, only there should be a longer period between sending the mails and releasing the app).

Seriously, a platform which requires its applications to be restricted by-definition to the current version (or earlier) ONLY is a bad platform. You just can NOT expect developers to keep updating their applications because the platform keep changing under their feet. A platform should be stable, and a basis developers can count on. Backward compatibility is such an important issue for applications and for the platform to succeed. For those of you who haven’t read Joel’s column on this issue, it’s a really good read: http://www.joelonsoftware.com/articles/APIWar.html

As it stands now, the platform forces an extension to declare that it will NOT work with any future version of the platform (that’s a direct implication of the compulsury existance of maxVersion). And this (currently) makes firefox[/gecko.mozilla/whatever] a bad platform which shoots itself in the foot.

It is, I hope, clear that having a maxVersion restriction kick in is functionally equivalent to a class 0 “breakage”, and is worse than a class 1 break. I do think that damaging breaks that go undetected by the community are quite rare. Perhaps not as rare as when the first comments in the bug were written, but still rare. Care to quote any examples? Virtually all of the breaks I’ve seen have been exposed by patches checked in to nightly builds.

Regarding having maxVersion targeting major point releases, the assumption has been that minor releases wouldn’t contain breaking functionality. The possibility was acknowledged, but not deemed likely enough to warrant much consideration. (IIRC this was before support for FVF strings like “1.0+” was checked in.) Anyways, I’ll quote Wolf himself:

“Development builds are just that, if an extension breaks and you required it..
well.. heh. you shouldn’t use that build. With this change, minApp and maxApp
target mainly milestone builds, I don’t personally believe it is unreasonable to
require authors to update a maxAppVer value before a major milestone.”

Regarding point 2: Ideally, there would be an easy way for UMO admins to re-package extensions with a new maxVersion. My point with the “community testing process” is that by the time the milestone is released, compatibility is Known, not Unknown.

I’d like to say that relying on just “the community” will never gain you good results. Unless there is a person who is in charge of doing X, there’s no guarantee it will be done. Leave alone the fact that nightly testers may not use all the 500 extensions available for Firefox.

Heh. You do realize that a not-insignificant portion of Firefox’s success is directly attributable to the community surrounding it? For promotion of the browser, creation of extensions, helping maintain bugzila, even for development of the core, Firefox’s community is one of the first-order forces contributing to its ongoing survival.
Also, what makes you think that the fact that there is someone in charge of X means it’ll get done? There’s plenty of contradictory evidence to be found with UMO, on the extension-developer and backend-development and administration sides. The developer panel was what, nearly a year late? UMO’s goal of only hosting “vetted” extensions proved to be such a burden that their collection essentially froze in time, leaving outdated and, occasionally (*gasp*) broken extensions being served from UMO. As I believe you well know, uninstalling Adblock 0.5, as hosted by UMO, leaves users with a broken profile. Where’s the maxVersion protection?

The problem with “bump[ing] maxVersion in UMO’s database” is that there’s no “database” in which maxVersion may be bumped — it’s a text file in a ZIP, and PHP has rudimentary zip-reading and no zip-writing support built in. Because it would be an uncommon operation, they could probably get away with a shell script to unzip and rezip.

I agree that having extensions break browsers is not good, but I simply think that maxVersion, as implemented now, is causing more harm than good.

Of course, the really fun bit in all of this is that it’s too late to do it right. Too many 1.0 installs require maxVersion now; as I noted in the bug desc., “I also think that this should be dealt with ASAP, as the longer it
goes unfixed, the harder it will be to fix.” On the other hand, remote update.rdf support has made maxVersion optional in fact if not in name. We now have all of the hassle with none of the protection. Happy joy.

Ben, I re-read the bug, and I think Wolf has explained everything very well. I’d like to add to what he says:

You make a few assumptions that are ungrounded at best:
1- negligible percentage of extensions break with new releases
2- those extensions that do break will be noticed by the “community of nightly testers” during development phase and extension’s author will release fixed version of extension or change maxVersion in update.rdf before “end-users” upgrade their apps.

For (2), I’d like to say that relying on just “the community” will never gain you good results. Unless there is a person who is in charge of doing X, there’s no guarantee it will be done. Leave alone the fact that nightly testers may not use all the 500 extensions available for Firefox.

Yes, maxVersion makes authors responsible for the testing, and they don’t like it. But it’s better than making the default action for extensions of “unknown” compatibility to allow installing them, which is what you propose in that bug.

I’m not saying that current implementation of idea is great, and I certainly can see your concerns here. I do believe, though, that breaking the browser for some non-techie people, just because probability of that is low (even if it’s in fact low), is wrong.

In my opinion, allowing more people (UMO editors?) to bump maxVersion in UMO’s database can help. Although I remember an argument against this, made by someone of UMO staff before 1.0, iirc, that this isn’t right, because if the version is bumped, and the extension isn’t fully compatible, it causes problems to the author. How ironic.

(btw, the “remember the changes in 1.8″ should be “remember the *tree* changes in 1.8″ in my previous comment. It didn’t like the angle brackets.)

Taking over an extension that is not maintained anymore is a pain in the a** I have filed a bug in bugzilla somewhere but I guess this is very low priority …
Clearely something needs to be done as some heavily used extensions bit rot on umo.