Where it makes sense, users should be able to download multiple updates at once and then have them install in the order specified by the update server.
Are you referring to installing a firefox update and extension updates at the same time? Multiple extension updates can already be installed at the same time, but firefox updates can't at the same time.
I think that what Chase means is this: If you are running Firefox 1.1 and the latest version out there is 1.1.4, the update service should download the following updates * FF 1.1 -> 1.1.1 * ... * FF 1.1.3 -> FF 1.1.4 And install them at once, instead of making you download each of those and restarting afterwards.
The solution for Firefox 1.5 is to have users download a full update when skipping over releases. Maybe at some point in the future we might want to support multiple patches, so giving this a future target ;-)
Target Milestone: --- → Future
Using recent branch nightlies, after being offline for a few days, I had to run "Help | Check for Updates" several times to get to the latest version. Not sure if the fix Darin mentions hasn't been done yet, if this is an artifact of testing mode, or if something is misbehaving on my system. But this FAQ: http://wiki.mozilla.org/Mozilla_QA_Community:Software_Update:FAQ didn't mention anything about it, so I thought I'd add a note.
See 306999 for nightlies patching
Summary: ability to allow installing multiple updates at once → ability to allow installing multiple release updates at once
There is no difference in the client between a release MAR patch or a nightly MAR patch. These types of updates are handled differently by the server and sent to the client for download and installation. This bug is meant to target the client's ability to update, not the server's ability to send updates grouped together. Bug 306864 and bug 306099 address the infrastructure/general update system issues.
Summary: ability to allow installing multiple release updates at once → ability to allow installing multiple updates at once
see bug 306864
Nominating this bug as blocking for one of 184.108.40.206, 1.8.1, and 1.9a1. Depending on what it would take, we should consider it for the earliest release of the three that it could happen in. Rationale: we're now spending a majority of time redundantly creating partial patches between releases. An example is that when we create a diff between Firefox 1.5b2 and 1.5 for en-US on Windows, most of this patch can be reused for the same update between fr, ga-IE, and every other locale on Windows. If we could install multiple updates at once, we could have the client install one patch per platform per update that contains most of the changes, then another patch for the locale-specific portions of the installation per platform per locale per update. For 1.5b2, 1.5rc1, and 1.5rc2 to 1.5, we currently have 285 partial patches using 123 MB. Contrast that with having 9 patches (3 updates, 3 platforms) containing the bulk of the ~700 KB of release differences and 285 patches containing the small localization changes between those releases (9.15 MB). Add branding specialization and there's another dimension that at least doubles the set of patches we need to create. The numbers only continue to grow. By unchaining the largest parts of the patch that aren't dependant on specializations of the releases' attributes (eg locale or branding), we can realize a cost savings in time to create the patches and disk space used for each release.
Too big, scary, and not even started to consider for .0.1
Flags: blocking220.127.116.11? → blocking18.104.22.168-
I think this bug is WONTFIX. IMO we should keep the client butt simple, and shift as much complexity as possible to AUS where it can be more easily modified. I think this bug should be fixed by having AUS update the client to the latest build.
After talking to Chase about this, I realize that what is really needed is just the ability to break a single update into component parts (multiple MAR files perhaps). What I objected to was using such a mechanism to update the browser from version 1.5 to 1.5.1 to 1.5.2 all in one shot. That wouldn't work properly without restarting the browser in between patch applications, which would be very ugly for users. (Why? Because things like nsPostUpdateWin.js need to run after an update, and updater may change after an update.) However, if we are only talking about factoring a single MAR into component parts then we can easily support downloading the separate files and staging them all to be applied by one invocation of the updater.
(In reply to comment #11) > What I objected to was using such a mechanism to update the browser > from version 1.5 to 1.5.1 to 1.5.2 all in one shot. That's exactly what I was hoping for. Whether it be for nightly builds, or because a computer just hasn't been updated in a while. > That wouldn't work > properly without restarting the browser in between patch applications, which > would be very ugly for users. Well, then wouldn't that be in scope for this bug, to not have to restart?
Assignee: bugs → nobody
QA Contact: bugs → software.update
Duplicate of this bug: 456187
OS: Windows XP → All
Hardware: x86 → All
Duplicate of this bug: 349579
This bug is about a series of minor updates. You don't have to update from e.g. 3.6.10 to .11, .12, .13, .14, and .15. Instead, we directly update to .15 using the complete mar. Skipping from e.g. 3.6.10 directly to the new major version 4.0 without going to the latest minor version 3.6.x first is a different bug. --> WFM.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
What he was requesting is to download multiple updates and applying them sequentially. Reopening for now though this will likely be wontfix'd
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #17) > (In reply to comment #16) > > See comment 9 and comment 10 I'm quite aware of comment #9 and comment #10 and for the most part agree. Please see http://www.mozilla.org/projects/toolkit/review.html under Application Update
Status: REOPENED → NEW
Summary: ability to allow installing multiple updates at once → ability to install multiple update mars during one update
So what are the use cases for this? 1) Incremental patches to go from .0 to .1 to .2 2) Apply common changes in one MAR and locale-specific changes in a separate MAR. I think that Mozilla has decided that for the first one it is easier and more cost effective to just deliver a full upgrade than multiple incremental updates. Is releng still interested in the second use case?
The incremental case isn't all that valuable because the partial mars can fairly quickly reach the size of the complete mar. A couple of the use cases: ability to create a non-locale mar and a locale mar. oem distributions with a base Firefox mar and a customization mar. The locale case is no longer possible since the locale is now in omni.jar The value of doing this isn't all that great and the additional complexity is rather high so I'm wontfixing this.
Status: NEW → RESOLVED
Last Resolved: 8 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.