Closed
Bug 698355
Opened 10 years ago
Closed 9 years ago
Add compatMode parameter to VersionCheck.php to allow updating to non-compatible addon versions
Categories
(addons.mozilla.org Graveyard :: API, defect, P2)
addons.mozilla.org Graveyard
API
Tracking
(Not tracked)
RESOLVED
FIXED
6.3.2
People
(Reporter: Unfocused, Assigned: robhudson)
References
Details
In bug 527141, I want to send an additional parameter ("compatMode") in the version update check, denoting what type of compatibility mode the extension manager is running in. The three possible values are: * strict - old-style compatibility checking, where addons are compatible only if they explicitly say they are. This is the same as the current behaviour. * normal - Addons are compatible by default. Same as "strict", except ignore the maxVersion - but only if it doesn't have a matching compatibility blacklist entry (see bug 692971). * ignore - when compatibility checking is disabled (ie, the extensions.checkCompatibility.VERSION pref is set to false). Same as "normal", except it ignores any compatibility blacklist. If the parameter is missing, it should be interpreted as "strict", so that old application versions get the same response as they do currently.
Reporter | ||
Comment 1•10 years ago
|
||
Almost forgot... addons can opt-in to strict mode. See bug 698358. So if Firefox sends compatMode=normal, but the addon has opted-in to strict compatibility mode in it's install.rdf, then VersionCheck.php should assume compatMode=strict
Comment 2•9 years ago
|
||
(In reply to Blair McBride (:Unfocused) from comment #1) > Almost forgot... addons can opt-in to strict mode. See bug 698358. So if > Firefox sends compatMode=normal, but the addon has opted-in to strict > compatibility mode in it's install.rdf, then VersionCheck.php should assume > compatMode=strict Can't we just send strict in this case to make things simpler on the server?
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #2) > Can't we just send strict in this case to make things simpler on the server? We can, and my patch does this, but it needs to be able to handle the case where the installed version doesn't opt-in, but the newer version does (and is incompatible). Otherwise it'll try to upgrade to an incompatible version - which will happen the first time any addon opts-in (this will primarily affect people running nightly/aurora/beta).
Comment 4•9 years ago
|
||
Actually I think it's not clear to me what this is about. We send compatMode to AMO in the URL? What is AMO going to use this for? Don't we also need compatMode to be included in the returned update.rdf so Firefox knows how to interpret the min/maxVersion info?
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #4) > Actually I think it's not clear to me what this is about. We send compatMode > to AMO in the URL? What is AMO going to use this for? Yep, because currently AMO will only send information about one update - the one it thinks is the latest that's compatible with the application version specified by the appVersion parameter in the URL. > Don't we also need > compatMode to be included in the returned update.rdf so Firefox knows how to > interpret the min/maxVersion info? We don't *need* it when it comes from AMO, since AMO only sends one update - we can just assume it sent an update that's compatible. But it will be needed for the update.rdf for addons that update outside of AMO - but only when they opt-in to strict compatibility checking.
Comment 6•9 years ago
|
||
I talked with a few devs today and what this bug needs isn't clear to us. Can we meet today and/or have more explanation of what AMO is doing? It sounds like filtering out stuff would be client side but I think we're just not understanding the bug.
Updated•9 years ago
|
Target Milestone: --- → 6.3.1
Updated•9 years ago
|
Assignee: nobody → chudson
Comment 7•9 years ago
|
||
Info here: https://etherpad.mozilla.org/jlkasdfjksadj
Updated•9 years ago
|
Priority: -- → P3
Target Milestone: 6.3.1 → 6.3.2
Updated•9 years ago
|
Priority: P3 → P2
Assignee | ||
Comment 8•9 years ago
|
||
https://github.com/mozilla/zamboni/commit/22ae51f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•