251148 - Make install.rdf's maxVersion arc optional

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Ben Karel [eschew]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

First, the "low-level", uninteresting part: Attempting to install an extension
lacking the maxVersion predicate and a corresponding value literal will fail.

The more abstract justification for the maxVersion arc to be optional is the
interesting part.

The goal behind the way maxVersion is currently used (I'm thinking of
update.mozilla.org as much as the EM) is certainly a good one; unfortunately,
nobody here can tell the future, and that's what is necessary to make the
current system actually work.

At a high level, the problem of an extension breaking compatibility with the
browser comes in two relevant classes: changes in the browser for which it is
feasible for the extension to code around, and changes for which a workaround is
unfeasible. The first class of problem ought to be coded around by the extension
author, with a corresponding update released with alacrity. In the days between
the incompatibility being discovered and a fix released, the XPIs hosted by the
author as well as update.mozilla.org and (ideally) any mirrors should have a
maxVersion arc added to prevent incompatibilities. When a fix is released, the
maxVersion arc may be removed. If the underlying platform changes in such a way
that the extension has no way of recovering its former functionality, the added
maxVersion arc will merely become permanent.

It should be noted that in either situation, a small number of users will
invariably attempt to install an extension that can break the browser, that
number will likely be comparable to or less than the number of users who
currently run in to problems due to u.m.o's policy of not hosting any extension
which won't break with the next FVF increment, and the lag time for any
extension hosted by u.m.o to get updated.

Another issue is that the majority of breaking changes do not appear in the same
release that gets its FVF bumped; most changes (like the nsIContentPolicy
changes that caused Adblock to fubar the browser) are, logically enough, checked
in during the development of the branch or trunk. To accurately constrain the
target installation, blocking as many incompatible users while allowing as many
compatible ones, install.rdf must be able to restrict based on nightly build
date identifiers (+ trunk/branch distinction). Thus, this bug depends on bug
250756. Resolution of this bug will obviously block UMO from hosting
maxVersion-less extensions, which is, I must confess, my ultimate goal here. 

Allowing an optional maxVersion also ought to ease the workload of those
responsible for administering Update. Instead of a flood of requests from
extension authors  to get their extension maxVersions updated whenever the
platform has its FVF changed, the admins will only have to update the rare
extension that breaks.

Finally, I would postulate that both the "bogus" maxVersions and the monkey
business with app.version for 0.9.1 are both symptoms of this design oversight,
and while both have been dealt with in their own way, they still do not cure the
root issue. I also think that this should be dealt with ASAP, as the longer it
goes unfixed, the harder it will be to fix; a large userbase does have some
drawbacks.

Oh, another note: the "insurance" provided to UMO by forcing extensions to
constantly play catch-up is by no means "free", and one of the drawbacks --
users being faced with a dialog informing of "incompatible" extensions -- is
counter to the goal expressed by alanjstr of being "all about stability."


Reproducible: Always
Steps to Reproduce:
1. Take an extension like Chris Pedrick's Web Developer and repackage it,
removing the line listing the maxVersion arc.
2. Attempt installation of repackaged XPI in a recent Firefox version with the EM.

Actual Results:  
The 2-second delay dialog appears, and nothing happens after the dialog is
dismissed.

Expected Results:  
The EM should allow the extension to install, treating the lack of a maxVersion
arc as being equivalent to a maxVersion with a literal value greater than the
current app.version (e.g. the extension should install normally).

Comment 1

[Oakwine]

Perhaps the maxVersion should not be included in the XPI, but on the server. 
(Please note, I am not an extension developer, so I might be using the incorrect
terminology.)  Since there is already a way for Firefox to check with the server
to see if there is an update, it could also check there to see if the extension
has been approved for the current Firefox version.

There could be flags set for "not yet verified" and "incompatable".  If it just
hadn't been verified yet, Firefox could provide a message informing that "This
extension has not been verified for 0.9.2; do you want to use it at your own
risk?".  For incompatable, "This extension does not work with 0.9.2; it has been
disabled".  

Comment 2

[Patrick Thompson]

My two cents worth:

REF: http://forums.mozillazine.org/viewtopic.php?p=609745#609745

I think this needs work because: 

In most cases, nothing will have changed between a x.y.0 and an x.y.Z version (this is especially true with themes.) 

1. Requiring extension and theme designers to create new builds every time a version changes, even when no code change is needed is wasteful of their time and resources. 

2. Requiring a user to update an extension/theme for the same reason is wasteful of their time and resources. 

3. Requiring a download from the internet for the same reason is wasteful of its bandwidth.

Perhaps a better solution would be for EM/TM to automatically highlight all extensions/themes orange (or some other "cautionary" indicator) when a version changes. Each one would remain that way until the extension/theme author set some "VERIFIED on x.y.Z" semifore flag as pointed to by the EM:update URL (via some attribute?). Alternately, the user should also be able to override the caution. This would not normally happen; however, in the event that extension/theme author doesn't respond with a VERIFY after a long period of time, the user may decide on their own that it now works. 

The above can easily be improved on, I'm sure, but the essence of what I'm suggesting is that an alternative method is needed rather than the existing one, imo.

Comment 3

[Ben Karel [eschew]]

Attachment: Allows for successful install when install.rdf lacks a maxVersion arc.

If there is no maxVersion arc defined, we pretend it was defined with a value
equal to the current app.id from prefs.
I had some trouble with getting the infrastructure for making the patch up and
running, so the top few lines are copied from
http://bugzilla.mozilla.org/attachment.cgi?id=153028&action=view and I changed
38 to 39.

Comment 4

[Ben Karel [eschew]]

(In reply to comment #3)
> Created an attachment (id=153109)
> Allows for successful install when install.rdf lacks a maxVersion arc.
> 
> If there is no maxVersion arc defined, we pretend it was defined with a value
> equal to the current app.id from prefs.
> I had some trouble with getting the infrastructure for making the patch up and
> running, so the top few lines are copied from
> http://bugzilla.mozilla.org/attachment.cgi?id=153028&action=view and I changed
> 38 to 39.

Sorry for the bugspam. That should be app.version, not app.id. Also, the
uploaded patch will probably be obsolete once version-checking is done via date
strings rather than with FVF strings.

Comment 5

[alanjstr]

Bug 249251 (app.extensions.version) definitely has an impact on this.  How do we
reconcile Firefox knowing its own compatibility level work with the range
established in install.rdf?  Does it look to see whether app.extensions.version
falls between minVer and maxVer and therefore the extension should still work? 
If that's the case, then why bother with a range?  Why not go back to what
contents.rdf did, which was have a single value for compatibility level.

Of course doing that now will destroy compatibility between 0.9 and 1.0 for
extensions.  

Comment 6

[Wolf [:wolf]]

(In reply to comment #5)
> Bug 249251 (app.extensions.version) definitely has an impact on this.  How do we
> reconcile Firefox knowing its own compatibility level work with the range
> established in install.rdf?

My understanding on Bug 249251, is that the second pref allows them to change
app.version to be accurate in 0.9.x type releases, preventing Software Update
notifications from breaking. The second pref is the extension version it
compares to.

Comment 7

[Wolf [:wolf]]

Addressing the comments here... Starting with Comment #2, themes/extensions
aren't broken between 0.9.x releases.. though most authors have been confused by
this. A 0.9 extension should work on 0.9.1 and 0.9.2, and all should in theory
have a maxAppVer of 0.9. It is possible that a subminor release could break
compatibility though, but in that case, Firefox's own pref for
app.extension.version, would be changed from say, 0.9 to 0.9.2.

minAppVer and maxAppVer are required values to define a range of known
compatibility.. as stated before, you can't predict the future.. which is why
extensions/themes that try are rejected from update. Having a null maxAppVer
defeats the purpose of the existance of these values. Based on what's said here,
that being null would allow a 0.9 extension to be installed into a mythical
future 1.8, which as we all probably well know, would never work. Once an XPI is
downloaded though, the maxVer is out of your control. So suddenly finding the
end-of-life value and then updating the file with that, will do nothing for the
users who have it installed.

Part of the (currently non-working) extension update mechanism, in the
specification anyway, when the Update service is called on new-version start, it
will check all the installed extensions against the update.rdf file and
webservice @ update. If the *same* version has been updated to be shown to be
compatible, then Firefox doesn't download it. It just updates its internal
maxAppVer and enables the extension.

Most of the users finding unexpected incompatible extensions, are probably using
0.9+ builds, which Update wrongly detects as being 0.9 and shows the list for
0.9, even though, 0.9 extensions didn't work in 0.9+... The change in Bug 249251
allows 0.9 extensions to work in 0.9+ (which in my opinion is a good thing).
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. The
"flood" of requests is a problem, but Update's planned control panel for
extension/theme developers will reduce that problem.

As far as the root of this bug.. that maxAppVer being absent breaks the install,
I'd think it's expected, as you've got a malformed install.rdf. ;-) It probably
should throw an error though.

"Resolution of this bug will obviously block UMO from hosting
maxVersion-less extensions, which is, I must confess, my ultimate goal here."
Mozilla Update doesn't host a maxVersion-less extension, so why is this your goal? 

"It should be noted that in either situation, a small number of users will
invariably attempt to install an extension that can break the browser, that
number will likely be comparable to or less than the number of users who
currently run in to problems due to u.m.o's policy of not hosting any extension
which won't break with the next FVF increment, and the lag time for any
extension hosted by u.m.o to get updated."
I'd say that being annoyed by a prompt about incompatibility is alot less
annoying than having your browser be broken. So far, the FVF hasn't changed
since Update was launched, so I doubt there's numbers available for how many
users have been affected. I'd argue that the number of users you're talking
about, is anything but small, and breaking the browser is what's trying to be
avoided by this system, because a broken browser is inexcusable, and leads to a
poor experience with Firefox, much more than a prompt.

This sounds like it relates Mozilla Update Bug 247357, which is about the
incorrect showing of 0.9 extensions to 0.9+ branch users.

I'd recommend this bug be marked as either invalid (expected behavior) or
wontfix. but that's up to the Firefox peers. :-)

Comment 8

[Ben Karel [eschew]]

>Having a null maxAppVer defeats the purpose of the existance of these values.
>Based on what's said here, that being null would allow a 0.9 extension to be
>installed into a mythical future 1.8, which as we all probably well know, would
>never work. Once an XPI is downloaded though, the maxVer is out of your control.
>So suddenly finding the end-of-life value and then updating the file with that,
>will do nothing for the users who have it installed.

It's not really a null maxVersion; one can also think of it as being a variable
maxVersion; that's what the code treats it as. Semantically, maxVersion should
not be a necessary datum to supply. Compatibility is currently either
"compatible" or "not compatible", but that's misleading; it's actually "not
compatible" or "unknown compatibility."

Regarding 0.9 being installed on 1.8: it's actually not entirely unlikely, and
certainly not impossible, as you seem to think. Adblock, for example, works with
all versions of Mozilla from 1.0 to 1.8 as well as Firefox, from 0.9.2 to some
pretty early version of Pheonix (not sure of the exact build).

As for an XPI from last week being compatible with a browser a year and a half
from now, that's more unlikely, but still not impossible.

Do you really think that someone would download an XPI tomorrow, keep it until
Firefox 2.0, and then try to install it? To me, that represents a considerable
enough effort on the part of the user that it's in the realm of them *trying* to
break compatibility.

It's true that users won't be able to take back the bandwidth spent on
downloading an incompatible extension, but presumably the user ought to still be
able to disable or uninstall any misbehaving extensions.


>As far as the root of this bug.. that maxAppVer being absent breaks the install,
>I'd think it's expected, as you've got a malformed install.rdf. ;-) It probably
should throw an error though.

Well, the "root of the bug" is not the fact that it fails with the current spec.
It ought to, since the spec specifies both minVersion and maxVersion as being
required. The point of the bug is that install.rdf shouldn't be considered
malformed if the maxVersion arc is missing.

>"Resolution of this bug will obviously block UMO from hosting
>maxVersion-less extensions, which is, I must confess, my ultimate goal here."
>Mozilla Update doesn't host a maxVersion-less extension, so why is this your >goal?

Well, Mozilla Update currently *cannnot* host maxVersion-less extensions because
they are currently considered malformed and do not install properly. That's not
the same as being opposed to the idea. As I noted, it would save everyone time,
especially around new releases.

>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. The
>"flood" of requests is a problem, but Update's planned control panel for
>extension/theme developers will reduce that problem.

So much for valuing stability. I agree that it's more reasonable to only update
for milestones, but it seems to me that all builds that aren't milestones are
being all but given the finger. Most if not all breaking changes are not checked
in along with a bump to the FVF, and that means that, following your advice, our
center of balance is still firmly anchored over square 1, since anyone not using
a milestone has no protection from extension incompatibilities.

If code is checked in tomorrow that breaks Adblock, the FVF will not change, and
thus Mozilla Update will be serving "broken" extensions, even under the current
scheme, and it'll be May 14th all over again.

Let me repeat that:
***
Even under the current scheme, the user can still download an incompatible
extension from update.mozilla.org!
***

Having many changes between FVF increments also means that a FVF-based
compatibility scheme is bound to exclude a pretty large number of users. 
If my message isn't as clear as I'd like it to be, please let me re-clarify.

And yes, it would be nice to have the control panel.

Marking as INVALID because the proposed behavior isn't the same as the current
behavior seems... irrational, at best.

In theory, a prompt is preferable to destructive incompatibility, but really, a
"broken browser" is not inexcusable, it is inevitable. The very existence of
bugzilla seems to imply that, if one loosens the definition of "broken."

Comment 9

[Patrick Thompson]

Ref: Comment #7

"Part of the (currently non-working) extension update mechanism, in the
specification anyway, when the Update service is called on new-version start, it
will check all the installed extensions against the update.rdf file and
webservice @ update. If the *same* version has been updated to be shown to be
compatible, then Firefox doesn't download it. It just updates its internal
maxAppVer and enables the extension."

I'm not privy to the spec but this sounds like a more reasonable approach. The
way I read the above, there will be some yet defined mozilla facility,
"webservice @ update" (w@u) that will contain some type of compatability matrix
for extensions/themes (e/t) hosted on UMO that contains, essentially, a "Works
With" list based on the e/t version number within the user's extension folder's
update.rdf file. It sounds like the w@u matrix will get updated via some
external means, e.g., the e/t author, to indicate whether their e/t works with
the latest release level. If so, then no redownload would be required.

If I'm understanding this correctly then this removes my major objection to the
current system, i.e., requiring e/t repackaging, re-uploading and re-downloading
even when no code change was necessitated (which will be the majority of the
cases, imo.)

Comment 10

[alanjstr]

Well, at the moment, UMO _only_ reads min and max from install.rdf.  They are
not currently changeable once the entry is made into the database.  If the
intention is for this to be changeable, then we need a bug for the backend
before we allow authors to update their own entries.

Comment 11

[alanjstr]

I think this is rendered moot by bug 251473

Comment 12

[Wolf [:wolf]]

(In reply to comment #8)

> Compatibility is currently either
> "compatible" or "not compatible", but that's misleading; it's actually "not
> compatible" or "unknown compatibility."

The Min and MaxAppVer values should currently be values that've been tested by
the author, to *be* compatible. So it's not misleading, unless of course, the
extension author is lying. (Which, unfortunately, i've seen, in the case of
MaxVer's greater than 0.9+)


> Well, Mozilla Update currently *cannnot* host maxVersion-less extensions because
> they are currently considered malformed and do not install properly. That's not
> the same as being opposed to the idea. As I noted, it would save everyone time,
> especially around new releases.

Saving time, and introducing a crop of extensions that the site claims is
compatible because it simply knows no better, under this logic anything from 0.9
would magically be compatible, unless an author swoops in and tells Update
otherwise, with 1.0. What about authors who've abdandoned their extension? In
order to ensure compatible, the time saved from having to update records, would
be spent testing and retesting extensions. Not an improvement.

> 
> So much for valuing stability. I agree that it's more reasonable to only update
> for milestones, but it seems to me that all builds that aren't milestones are
> being all but given the finger.

What part of the definition of a development nightly are you missing? They're
not even guaranteed to run, let alone have extensions work.

> Most if not all breaking changes are not checked in along with a bump to the
> FVF, and that means that, following your advice, our center of balance is
> still firmly anchored over square 1, since anyone not using a milestone has
> no protection from extension incompatibilities.

Correct, the FVF will be bumped at the end of the development cycle. Users using
nightlies are in an at-your-own-risk enviroment. Same as they always have been.

> If code is checked in tomorrow that breaks Adblock, the FVF will not change, and
> thus Mozilla Update will be serving "broken" extensions, even under the current
> scheme, and it'll be May 14th all over again.


If code is checked in tomorrow, that means that it's during 0.9+ the development
cycle. The idea you haven't gotten here, is that development nightlies aren't
guaranteed, not by mozilla.org and not by Update or the EM. and your proposal
certainly doesn't change anything if Adblock was suddenly broken tomorrow. IMO,
it provides less protection, since if the author didn't return, the maxVersion
variable extension would float into 1.0. broken.

> In theory, a prompt is preferable to destructive incompatibility, but really, a
> "broken browser" is not inexcusable, it is inevitable. The very existence of
> bugzilla seems to imply that, if one loosens the definition of "broken."

Broken, under my definition, means not working because of an broken extension
was installed, which isn't acceptable.  Broken/Buggy-code is a different topic
entirely.

Comment 13

[Wolf [:wolf]]

Yeah, Bug 251473 is the feature I was in reference to.. The original
specification I read had it included, I didn't realize it hadn't been
implemented and wasn't laying in wait in 0.9 though.

(In reply to comment #9)
> If I'm understanding this correctly then this removes my major objection to the
> current system, i.e., requiring e/t repackaging, re-uploading and re-downloading
> even when no code change was necessitated (which will be the majority of the
> cases, imo.)

Well, it doesn't releave the burden of repackaging from the E/T authors..
Basically, they update the XPI that's hosted with update (same-version update,
its just replacing the current file with the new one), and the database backend
gets updated with the new version data. The Update webservice when called upon,
sends Firefox the  Extension X Version 1.0 works with say 0.9-1.0. which is
different than what Firefox knows.. (Extension X Version 1.0 -- 0.9-0.9) so it
just updates it's internal info. The file update is also for new users of the
extension, so the EM doesn't reject it.

Comment 14

[PikeUK]

There's more to extensions than UMO, it is perfectly reasonable for an
individual or company to want to make an extension for their own use which never
"expires". If UMO doesn't want to host extensions without a maxversion that is
fine but it it irrelevant to this bug.

Comment 15

[alanjstr]

(In reply to comment #14)
> There's more to extensions than UMO, it is perfectly reasonable for an
> individual or company to want to make an extension for their own use which never
> "expires". 

So then they can put a maxVersion of 999 on it.  

Comment 16

[PikeUK]

(In reply to comment #15)
> So then they can put a maxVersion of 999 on it.  

Yep exactly, either authors can be forced to do things like that or maxVersion
can be made optional, either way the result is the same, but implementing this
bug is the cleaner solution.

Comment 17

[alanjstr Component Watcher]

By changing them to optional, we have to recode UMO, Firefox and TB.  Since
bogus values get you to the same place, why bother changing the RDF spec?

Comment 18

[PikeUK]

(In reply to comment #17)
> By changing them to optional, we have to recode UMO, Firefox and TB.  Since
> bogus values get you to the same place, why bother changing the RDF spec?

So the release of Firefox 2005 doesn't break my maxVersion=999 hack :-) Of
course if it really is a huge amount of work to fix then a WONTFIX here wouldn't
be the end of the world, but getting the format right shouldn't be abandoned
just because it would require more work (says the lazy commenter).

Err sorry about the spam I didn't intend to write 3 comments.

Comment 19

[Patrick Thompson]

REF: Comment #13

Okay, I believe I've got it now. As long as the e/t author doesn't bump THEIR e/t version number but only the Ff/Tb maxVersion number, then the plan is to have the back end system note that and, thus, not initiate a client download.

While this still requires the author to repackage (unclear if bug 251473 remedies that, even?), it will go a long ways in not upsetting the install base with endless and unnecessary e/t download alerts.

Comment 20

[alanjstr]

Geez, sailfish, why do you keep stretching my screen?

Anyways, yes, I think bug 251473 remedies the situation.  But I'll let Ben make
that call.  Although I don't think it would specifically be UMO, but the
update.rdf that it generates.

Comment 21

[Patrick Thompson]

alanjstr, I'm not sure what's going on here, sometimes it breaks okay and other times not? Gremlins??

Comment 22

[Ben Karel [eschew]]

(In reply to comment #17 from alanjstr)
> By changing them to optional, we have to recode UMO, Firefox and TB.  Since
> bogus values get you to the same place, why bother changing the RDF spec?

Well, the patch above ought to work for both Firefox and TB, since I assume they
use the same core E/T-managing code. As for UMO, it seems like the necessary
changes would be a frontend tweak or two and a few backend changes (allowing for
the possibilty of no maxVersion in the auto-import code, and allowing the site
admins + authors to change maxVersion without putting up a new XPI). The first
backend change ought not to be too difficult, and the second really should be
implemented regardless of the status of this bug. Out of curiosity, has the
backend to UMO been released, and if so, where could I find it? I would
certainly be willing to take a look through to see what needs to be changed.



(In reply to comment #8 by Wolf)

>> Compatibility is currently either
>> "compatible" or "not compatible", but that's misleading; it's actually "not
>> compatible" or "unknown compatibility."

> The Min and MaxAppVer values should currently be values that've been tested by
> the author, to *be* compatible. So it's not misleading, unless of course, the
> extension author is lying. (Which, unfortunately, i've seen, in the case of
> MaxVer's greater than 0.9+)

By "misleading," I wasn't really referring to the current state of affairs so
much as the semantic "ideal," what "ought" to be. Apologies for the
inappropriate wording; "it's actually" should have been "it should actually be".

Statistically, though, it's overwhelmingly likely that any given extension or
theme will be compatible with the next release of the E/T's platform, so the
author is not lying; rather, merely giving the most statistically accurate
information he or she is currently aware of. The majority of extensions
downloadable from UMO today will, in fact, be compatible with Firefox 1.0, but
the current system considers them to be incompatible, rather than a more
accurate way of thinking of it (unknown compatibility).

A question: If/when the EM starts using build dates, rather than or in addition
to FVF versions, will you require the maxVersion to be no higher than the
current nightly, updated every single day? That seems the logical extension of
the current policy, which says that only builds that have been tested by the
author may be put in the maxVersion predicate.


> [...] anything from 0.9
> would magically be compatible, unless an author swoops in and tells Update
> otherwise, with 1.0. What about authors who've abdandoned their extension? 

Well, the author would have a good three to four months in which to "swoop in."
For authors who have abandoned their extension, I suppose the most logical thing
to do would be for UMO to host the extension until an incompatibility presented
itself, and then either change the maxVersion to stop new installations, or
delist the extension completely.



> In order to ensure compatible, the time saved from having to update records, would
> be spent testing and retesting extensions. Not an improvement.
...
> Correct, the FVF will be bumped at the end of the development cycle. Users using
> nightlies are in an at-your-own-risk enviroment. Same as they always have been.
...
> What part of the definition of a development nightly are you missing? They're
> not even guaranteed to run, let alone have extensions work.

The "testing and retesting" of extensions would be done entirely by nightly
users, whom you have pretty much already dismissed out of hand, so why are you
suddenly so concerned over whether or not their no-warranty nightly build has a
problem with an extension? That's not a rhetorical question, by the way -- I'm
interested in the answer.


>> If code is checked in tomorrow that breaks Adblock, the FVF will not change, and
>> thus Mozilla Update will be serving "broken" extensions, even under the current
>> scheme, and it'll be May 14th all over again.

> If code is checked in tomorrow, that means that it's during 0.9+ the development
> cycle. The idea you haven't gotten here, is that development nightlies aren't
> guaranteed, not by mozilla.org and not by Update or the EM. and your proposal
> certainly doesn't change anything if Adblock was suddenly broken tomorrow. IMO,
> it provides less protection, since if the author didn't return, the maxVersion
> variable extension would float into 1.0. broken.

Er, no. As noted in the original description for this bug (end of paragraph 4),
if an extension breaks during the dev-period between releases, the maxVersion
arc on the server would be updated by either a site admin or the extension/theme
author. I'd assumed that that capability was already in UMO, but apparently it
isn't; thus, this bug ought to depend on that capability being added, in
addition to date-based versioning. That way, only a few nightly users will end
up having their browser break, and since their builds are not "gauaranteed," no
worries, eh?

Really, in either scheme, those using milestone releases to donwload extensions
are virtually guarateed compatibility. The main issue has to do with those using
nightlies: 

Consider this: not all 0.9+ dev builds have been released yet, so to be totally
honest, authors shouldn't use the  +  indicator on their FVF compatibility
strings. The problem is that two different builds bearing the same FVF can have
different compatibilty statuses with any given extension.

With your scheme, if an extension becomes broken due to a nightly change, the
author must repackage his extension, but there's a lag time of about a week for
that to get through the system, and then another week for the fixed XPI to come
out, and until it does, all the current nightlies are deemed incompatible.

With my scheme, if an extension becomes broken due to a nightly change, the
author simply adds a new maxVersion date corresponding to the day the change was
checked in. All builds that are in reality compatible remain so, and those that
are not compatible are correctly marked as being incompatible.


>> In theory, a prompt is preferable to destructive incompatibility, but really, a
>> "broken browser" is not inexcusable, it is inevitable. The very existence of
>> bugzilla seems to imply that, if one loosens the definition of "broken."

> Broken, under my definition, means not working because of an broken extension
> was installed, which isn't acceptable. Broken/Buggy-code is a different topic
> entirely.

As noted above, since pretty much all breaking code changes are checked in
during the dev period and not a day or two before the official release, those
using official releases won't be at risk for having their browser break due to a
misbehaving extension. Unless, of course, it's a subtle bug that is hard to
track down...

I think Pike hit the nail on the head here:
>> So then they can put a maxVersion of 999 on it.  
> Yep exactly, either authors can be forced to do things like that or maxVersion
> can be made optional, either way the result is the same, but implementing this
> bug is the cleaner solution.

We can fix the symptoms, or we can fix the root cause. Antoine de Saint-Exupery
once said, "A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away." Having 0.9.1+
and above masquerade as 0.9 may fix one of the symptoms of this bug, but it's
essentially a hack that adds complexity rather than removing it.

Comment 23

[alanjstr]

(In reply to comment #22)
> (In reply to comment #17 from alanjstr)
> use the same core E/T-managing code. As for UMO, it seems like the necessary
> changes would be a frontend tweak or two and a few backend changes (allowing for
> the possibilty of no maxVersion in the auto-import code, and allowing the site
> admins + authors to change maxVersion without putting up a new XPI).

That's bug 251795, which Wolf has WONTFIX'd.  So we're not going to get anywhere
unless Ben comes in and overrules him.

Comment 24

[Wolf [:wolf]]

Ben doesn't need to overrule me on that bug, for the decision to change. I'll
reverse the decision and implement it, if the EM changes in a way where it'd be
a good idea for Update to do so. Pike is right, this bug can be implemented for
organizations that need such function, seperate from Update. Update and the
Extensoin Manager are related and depend on one another, but do not have the
same requirements.

Extension Manager doesn't magically check the central-update host when you
install a new extension for the first time to get the compatibility data, that
comes from a static file inside the extension (install.rdf). So, if you
magically update DB data, and don't fix the file, then the point is lost. The
file would still say the previous info, which is why update requires the
repackaging/reuploading to keep the info between file and DB synchronized, which
is how Ben's specification for Update's function says to handle it. Bug 251795
requests a feature that breaks that, which is why it was wontfixed.

This bug suggests making maxVersion optional.. under the belief, that the
restriction is somehow unfair, and that perfectly functional extensions are
being broken because it doesn't support (and disallows) "Unknown Compatibility".
In my view, this is acceptable, unless it's verified-compatible, it shouldn't
work, advanced end-users can edit the install.rdf by hand anyway. Update's goal
is to provide known-compatible extensions to end-users. Being known comes in the
form of testing, and author's providing valid min/maxVersions.
To make maxVer optional in the file, returns the previous (0.8) style function,
where there's no limit, and you suddenly find out something changed to break
stuff when your browser is horked, which has never been acceptable in an
end-user destined product. End-Users don't have the knowledge that Firefox
community testers do, to recover from bad extensions, and every bad extension
that exists places a black-mark on the image of Firefox's extensibility, which
is one of the strongest marketting points Firefox has. So I don't feel this
feature is a good idea for the masses.

(In reply to comment #22)
> The majority of extensions
> downloadable from UMO today will, in fact, be compatible with Firefox 1.0, but
> the current system considers them to be incompatible, rather than a more
> accurate way of thinking of it (unknown compatibility).

Update disallows unknown, same as it disallows incompatible, correct.

>
> A question: If/when the EM starts using build dates, rather than or in addition
> to FVF versions, will you require the maxVersion to be no higher than the
> current nightly, updated every single day? That seems the logical extension of
> the current policy, which says that only builds that have been tested by the
> author may be put in the maxVersion predicate.

That feature being implemented, wouldn't currently affect update. Update tracks
FVF, not the Build IDs. At the moment, Update's function doesn't limit
development periods currently. 0.9+ would allow it to go till the end of the
cycle. I don't see a reason to change that, if that feature was implented.
Particularly not to the absurd requirement of daily verifying. It's reasonable
for milestones, not for daily BuildIDs.

> The "testing and retesting" of extensions would be done entirely by nightly
> users, whom you have pretty much already dismissed out of hand, so why are you
> suddenly so concerned over whether or not their no-warranty nightly build has a
> problem with an extension? That's not a rhetorical question, by the way -- I'm
> interested in the answer.

Update's focus is on milestones (with each milestone extensions/themes are
verified to be compatible, currently, the system allows us to feed from the info
the authors provide in their updates.) and functionally it ignores nightlies.
Now that the EM follows suit (0.9 Extension will install on 0.9+ development
builds, for better or worse), this makes that gap in Updates functionality moot.
That's not to say I don't care if Extensions break in an nightly, while for alot
of them its unavoidable, particularly on trunk builds, but it is a caveat of
using the build. Update doesn't currently show any detail about known problems
with nightlies for an extension, in the next version, there'll be a developer
comment section, which I hope, authors will use to inform the community of known
nightly bustage outside of Update's current milestone verification features.

Comment 25

[alanjstr]

*** Bug 251289 has been marked as a duplicate of this bug. ***

Comment 26

[Wolf [:wolf]]

http://www.mozilla.org/projects/firefox/extensions/update.html

For those who are interested, in light of the above documentation, Bug 251795
has been reopened, and will be implemented by Fx-1.0.

Comment 27

[alanjstr]

I have a strong feeling that in light of the recent changes, this bug will be
WONTFIX.

Comment 28

[Benjamin Smedberg]

We definitely *do* want to force a maxVersion arc for ordinary usage. There is
no way to determine that an extension will be compatible with future releases,
and the point of the maxVersion arc is to protect users and extension authors
from untested combinations.

Very sorry I did not see this bug sooner.

Comment 29

[Xavier Robin]

Pref extensions.checkCompatibility allows to install and use "incompatible" extensions. I think this bug should be marked WORKSFORME or DUPLICATE of Bug 330895 ?