I just did a complete test matrix for en-US and de as available for updates to 2.1b2 build 2, and with the partials that come by auto-update for 2.1b1 it misses all extensions/*.xpi files (the builds run, but have no themes or extensions listed), but complete updates succeed even there and have them. See attachment 511579 [details] for the full test matrix. If this is true for all platforms, it may not be a one-off problem with what the updates factory produced, and we should investigate this later, but for now, we can dodge the problems by only delivering complete updates. The partial is 12M while complete is 19M this time, so this should not even cause a too large increase for people (and servers can easily take SM loads anyhow).

fixed for b2 only: by removing the partial mars this is a b3 blocker to make sure we get it right next time

I'm not resolving, but it looks like this will be fixed for b3, from my code inspection (which partial mar code inspection is not easy) Basically I found: http://mxr.mozilla.org/mozilla/source/tools/update-packaging/make_incremental_updates.py?mark=35-37#33 Which in the partial mar does this: *If added file begins with 'extensions/' ** Do add-if for extensions/ file.split("/")[1] which tests if its a dir-based extension and test for the existence of that. It doesn't expect the single-file based extension (.xpi) but we are one. The problem arose from us changing to a .xpi instead of dir in our release, so the packaging add for this, was actually MISSING our new .xpi's because they did not exist before. New (2.1b2 and up) installs should catch this and update appropriately from now on [if the user installed the extension to begin with] Old (2.1b1 2.0 etc.) will never work with a partial mar the way this packaging is setup. I don't know an easy way though as this is a tricky bit of code. So the best answer will be SURE not to have partial updates on for our 2.0->2.1 release. Since we only generate partials in beta releases from newest-beta to "next beta" we won't have an issue of 2.1b1 -> 2.1b3 updates.

(In reply to comment #2) > Old (2.1b1 2.0 etc.) will never work with a partial mar the way this packaging > is setup. Hrm, we usually have major updates do partials, AFAIK. Will we also have that problem when the extensions get moved to distribution/extensions/ instead?

(In reply to comment #3) > (In reply to comment #2) > > Old (2.1b1 2.0 etc.) will never work with a partial mar the way this packaging > > is setup. > > Hrm, we usually have major updates do partials, AFAIK. Will we also have that > problem when the extensions get moved to distribution/extensions/ instead? Not according to what I see in code. But of course will need testing

Based on my digging, the partials we will generate for b3 (from b2) will be fine, we won't be generating partials for any other version with b3. For final, we will (probably?) have partials from 2.0.x on the MU, so still blocking final.

This should be fixed in b3, right? In that case (i.e. if that can be confirmed), mark it as such and get rid of a blocker. :)

(In reply to comment #6) > This should be fixed in b3, right? In that case (i.e. if that can be > confirmed), mark it as such and get rid of a blocker. :) I'm leaving open and blocking, as this *could* (theoretically) manifest in MU from 2.0. I want to verify that it won't before I resolve.

prelim MU testing indicates this is not an issue.