295889 - Too many extensions (and themes) break on minor upgrades - need better system. Also, Firefox seems to ignore the plus character (i.e. 1.0+) in maxVersion field of RDF files.

Status: RESOLVED INVALID

(Toolkit :: Application Update, defect)

Description

[Tim LePes]

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!

Comment 1

[Mike Connor [:mconnor]]

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.