User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050526 Firefox/1.0.4 (Ubuntu package 1.0.4) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050526 Firefox/1.0.4 (Ubuntu package 1.0.4) When upgrading Firefox, too many extensions break. Especially when the upgrade is only a minor version (i.e. 1.0.x to 1.0.y). Reproducible: Always Steps to Reproduce: 1. Do a minor version upgrade to Firefox 2. Start browser after upgrade 3. Check the list of extensions (Tools > Extensions), or simply note the warning message on initial program load about extensions (and themes) that are now being disabled. Actual Results: Too many extensions break, including those with plus characters on the maxVersion string in the RDF (i.e. 1.0+). Users must manually download the XPI's and hack the maxVersion fields in the RDF files, or simply wait for the extension authors to release updated packages. Attempting to re-install the extensions from the Mozilla site (or others, like extensions mirror) fials also. Expected Results: Most or all extensions should survive a minor upgrade. Extensions with a plus character in the maxVersion field of the RDF (i.e. 1.0+) should still be enabled. (Re)installing extensions over the web should not be failing either. This is going to be the bane of Firefox if it is not addressed. Having a relatively lightweight browser with extensions is a great system. But users are going to be regularly irritated if large numbers of extensions break with every minor upgrade (such as a security update). Manually downloading the XPIs and hacking the RDF files to bump maxVersion is kludgy at best, and beyond many users' ability and/or comfort level. Expecting all the extension authors to scramble and release updated packages is poor logistics. There must be a better way... Here are some ideas, though: I have never developed extensions, so I am unfamiliar with how they work. If there is an API they use, or a core feature set, then perhaps Firefox should be using a different versioning system for extesnsions. Like an extension API version string that is used to manage extension compatibility. This would separate the extensions from suffering incompatibility with every minor or security update. Perhaps this can be dealt with at a policy level. Firefox carries a 3-decimal version number, such as 1.0.4. Maybe extension compatiblity can be managed at the second-decimal place and ignore the third decimal place. In other words, a 1.0.x to 1.0.y upgrade will not break extensions, but a 1.x.z to 1.y.0 update may. Policy on Mozilla's end would include mandating that changes which are likely to affect extension compatibilty require a second-decimal increment. I have noticed that many extensions use a plus character in the maxVersion string in the RDF now. You can even see the plus character being used on Mozilla's own extension list (on the web). Yet Firefox seems blissfully unaware that a 1.0+ maxVersion means 1.0.4 should run the extension. Ugh! What is the point, then? This must be very frustrating to users across the board. Where did this convention come from? Mozilla? Or did extension authors come up with this on their own, hoping it would fly? Perhaps some useful guidelines for maxVersion could be helpful. Maybe suggesting the author of a new extension for, say. 1.0.4, could put the maxVersion in the RDF to 1.0.9 as a rule of thumb. Then there will be no worries for bumping package versions until 1.1 rolls out. Or maybe some wildcard suport. How do you deal with non-numeric characters in the version string, like "RC" or the "+" I already mentioned? Maybe 1.0.9 will break if there is a 1.0.10 before a 1.1 release. In that case, would a wild-card support be feasable, such as "1.0.x" in the maxVersion string? That would allow Firefox to enable the exension for anything that starts 1.0 without regard to the last decimal. Or a "1.x" will work for everything until 2.0. Okay that is the best I can think of for now. I trust that you folks knowledgable in writing extensions (and themes, let's not forget) can come up with some sensible answer to this problem. Just to note, I also made comments on this in the Ubuntu Linux bugzilla #10681 at https://bugzilla.ubuntu.com/show_bug.cgi?id=10681 Thanks!
Firefox uses an app.extensions.version pref set to 1.0 by default, I don't know if Ubuntu's packages are messing with that pref. maxVersion=1.0 works with all 1.0.x builds from mozilla.org. 1.0 == 1.0.x, and 1.0+ does not mean 1.0.x. There's some discussion about changing versioning systems to better differentiate development and stable versions going on right now, but that's a cosmetic/understandability issue, not a technical one. Marking INVALID, since the functionality you're looking for already exists, but if Ubuntu is screwing with versioning and prefs, we can't control that.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.