When the schema of AddonRepository's database has a significant change, there can be new rows or tables that make an important contribution to the functioning of the Addons Manager - such as compatibility overrides. Ideally, we want to populate that with fresh data as soon as possible.

Dave, do you see any downside to this approach?

Comment on attachment 578957 [details] [diff] [review] WiP v1 Trying the update.js/selectAddons.js route, as suggested on IRC.

Comment on attachment 579041 [details] [diff] [review] Patch v1 Review of attachment 579041 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/extensions/content/selectAddons.js @@ +128,1 @@ > Looks like you left two blank lines here

Fixed re-disabling the cache at the end of the test. https://hg.mozilla.org/integration/fx-team/rev/109bb6c0e72a

Comment on attachment 579041 [details] [diff] [review] Patch v1 Preemptively requesting approval (it's not merged into central yet). Important piece of the compatible-by-default story, required for enabling it on a release version.

This should land on M-C before Aurora approval is granted.

Comment on attachment 579041 [details] [diff] [review] Patch v1 [Triage Comment] Approving low-risk add-ons default to compatible bugs for Aurora with the understanding that we're going to come up with explicit methods of tracking any regressions in aurora/beta related to this and stay on top of them. Please land on aurora only when this has been landed on m-c.

Note: The patch here is dependent on the patch in bug 693906. And that can't land on Aurora until bug 707328 can also land on Aurora. Dependency chains are fun.

Is this something QA can verify?

Kinda... it's a little awkward to do so at the moment, because AMO only has one compatibility override (that I know of), and that's for Addon Compatibility Reporter v1.0 and below. But there's v1.0.1 and v1.0.2 out now, which don't have a compatibility override... so you have to make sure Firefox doesn't automatically upgrade to those versions. 1. Start Firefox 9 2. Disable addon update 3. Install ACR v1.0 4. Disable ACR (useful because that version disables compatible-by-default) 4. Upgrade to Firefox 10 or higher 5. ACR should be marked as incompatible Without the fix from this bug, ACR would only be made incompatible after the first background update check after the upgrading to Firefox 10 or newer.

Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (X11; Linux x86_64; rv:11.0a2) Gecko/20120102 Firefox/11.0a2 Verified on Firefox 10 (Beta 2) and 11 (Aurora) on ubuntu 11.10, Mac OS 10.6 and Windows 7. Disabled ACR version 1.0 is listed as incompatible after the upgrade.