We've got a lot of confusing terms surrounding updates, so here is a list of terms, and exactly what I mean by them in this context: - Major update: A set of update snippets that point one major branch to another (eg, 3.5.x -> 3.6.x) - Major update automation: The collection of scripts, BuildFactorys, and release config variables that generate a Major update. Collectively, these are used in the "major_update" builders. - Background update: An update that Firefox downloads and applies at next restart. Requires no user interaction or acceptance. Generally identified by lack of presence of "updateType" in snippets. - Advertised update: An update that Firefox prompts the user to accept before downloading and applying it. Generally identified by "updateType=major" in snippets. To fix this bug, I believe we need to do the following: - Add a updateType option to MajorUpdateFactory -- When "major", "--update-type=major" should be passed to patcher-config-creator.pl and "--major" should be passed to update-verify-bump.pl -- When "minor", neither of the above options should be passed. - Add a "majorUpdateType" variable to all release configs, set to "major" for now. - Adjust release.py to pass this option along to MajorUpdateFactory

For 3.5 EOL, could we do one of the following: * Run the usual major update builders to generate 3.5.19 -> 3.6.18. Post-process the snippets to remove "updateType=major" * Run the 3.6.18 minor update builders again with oldVersion set to 3.5.19.

(In reply to comment #1) > For 3.5 EOL, could we do one of the following: > > * Run the usual major update builders to generate 3.5.19 -> 3.6.18. > Post-process the snippets to remove "updateType=major" This would be the best way. We may want to change the release notes URL to something different than usual, not sure. > * Run the 3.6.18 minor update builders again with oldVersion set to 3.5.19. This would require a custom built patcher config, or we'd get a bunch of extra snippets for all the past 3.6.x releases.

(In reply to comment #2) > > * Run the 3.6.18 minor update builders again with oldVersion set to 3.5.19. > This would require a custom built patcher config, or we'd get a bunch of > extra snippets for all the past 3.6.x releases. This would also get us partials, which we have a policy decision not to do for major updates. I think we will also need this functionality for doing 4.0* -> 5.0 on beta (and later release), but we can also handle that by using the major update path and remove 'updateType=major' afterwards.

(In reply to comment #3) > I think we will also need this functionality for doing 4.0* -> 5.0 on beta Apparently not, at least initially. Going to be a major update for 3.7a3-3a5 & 4.0b1-12. Long term, we're going to want to do things like all 5.0 builds, all 6.0 builds, previous 7.0 builds -> latest 7.0 build on beta & release, as a minor update. So that's more like in-branch configs we have now, just growing for ever more.

(In reply to comment #4) > (In reply to comment #3) > > I think we will also need this functionality for doing 4.0* -> 5.0 on beta > > Apparently not, at least initially. Going to be a major update for 3.7a3-3a5 > & 4.0b1-12. Where did you hear this? We will need it. At the very least we will minor update everyone with 4.0/4.0.1 on the beta channel to the 5.0 beta

and we want to do /that/ within a week of the aurora->beta merge next Tuesday

FWIW, that's why this bug was originally written. It just so happens this work will be the same/similar for 3.5's EOL plan.

There should be auto-update, but there are problems like: Delicious extension is very good and has no alternative, and is endemic that hasn't been updated yet since FF4 was released. Even so, there was no reason to make it incompatible, since other people found a way to bypass that and works: http://www.mydigitallife.info/how-to-install-or-force-enable-incompatible-add-ons-in-firefox-4-beta/ http://forums.macresource.com/read.php?1,1125540,1125571

There is a plan for anything compatible with 4: http://blog.mozilla.com/addons/2011/04/19/add-on-compatibility-rapid-releases/

I have experienced other types of issues with the auto-updater: language pack is not updated after language changed. For example: 1) Download portable firefox: http://downloads.sourceforge.net/portableapps/FirefoxPortable_4.0_English.paf.exe 2) Download custom language pack and install: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/win32/xpi/ 3) Change the interface language to the new one: about->config->useragent.locale 4) Restart browser and see that language has changed. 5) Update firefox to 4.0.1. It is using again english (custom set languages are not auto-updated). This is annoying. If this should go into a different bug please tell.

(In reply to comment #10) > I have experienced other types of issues with the auto-updater: language > pack is not updated after language changed. For example: > > 1) Download portable firefox: > http://downloads.sourceforge.net/portableapps/FirefoxPortable_4.0_English. > paf.exe > > 2) Download custom language pack and install: > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/win32/xpi/ > > 3) Change the interface language to the new one: > about->config->useragent.locale > > 4) Restart browser and see that language has changed. > > 5) Update firefox to 4.0.1. It is using again english (custom set languages > are not auto-updated). This is annoying. > > If this should go into a different bug please tell. Yes, please file a new bug in Firefox: General.

Bug added: https://bugzilla.mozilla.org/show_bug.cgi?id=657599

Mass move of bugs to Release Automation component.

I doubt we'll bother with this prior to Balrog being in production -> WONTFIX.