Closed
Bug 251148
Opened 20 years ago
Closed 19 years ago
Make install.rdf's maxVersion arc optional
Categories
(Toolkit :: Add-ons Manager, enhancement)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: eschew, Assigned: bugs)
References
Details
Attachments
(1 file)
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).
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•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
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.
Reporter | ||
Comment 4•20 years ago
|
||
(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.
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.
Summary: install.rdf's maxVersion arc should be optional → Make install.rdf minVersion and maxVersion optional
Comment 6•20 years ago
|
||
(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•20 years ago
|
||
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. :-)
Reporter | ||
Comment 8•20 years ago
|
||
>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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
I think this is rendered moot by bug 251473
Comment 12•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
alanjstr, I'm not sure what's going on here, sometimes it breaks okay and other times not? Gremlins??
Reporter | ||
Comment 22•20 years ago
|
||
(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.
Summary: Make install.rdf minVersion and maxVersion optional → Make install.rdf's maxVersion arc optional
Comment 23•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 251289 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
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•20 years ago
|
||
I have a strong feeling that in light of the recent changes, this bug will be WONTFIX.
Comment 28•19 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•19 years ago
|
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 29•16 years ago
|
||
Pref extensions.checkCompatibility allows to install and use "incompatible" extensions. I think this bug should be marked WORKSFORME or DUPLICATE of Bug 330895 ?
You need to log in
before you can comment on or make changes to this bug.
Description
•