ability to install multiple update mars during one update

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
14 years ago
5 years ago

People

(Reporter: chase, Unassigned)

Tracking

unspecified
Future
Points:
---
Bug Flags:
blocking1.8.0.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
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.

Comment 1

14 years ago
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.

Comment 2

14 years ago
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.

Comment 3

13 years ago
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

Comment 4

13 years ago
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.

Comment 5

13 years ago
See 306999 for nightlies patching
Summary: ability to allow installing multiple updates at once → ability to allow installing multiple release updates at once
(Reporter)

Comment 6

13 years ago
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

Comment 7

13 years ago
see bug 306864
(Reporter)

Comment 8

13 years ago
Nominating this bug as blocking for one of 1.8.0.1, 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.
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Too big, scary, and not even started to consider for .0.1
Flags: blocking1.8.0.1? → blocking1.8.0.1-

Comment 10

13 years ago
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.

Comment 11

13 years ago
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.

Comment 12

13 years ago
(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

Updated

12 years ago
Flags: blocking1.9a1?
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
Duplicate of this bug: 456187
OS: Windows XP → All
Hardware: x86 → All
Duplicate of this bug: 349579

Comment 15

8 years ago
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 → ---

Comment 17

8 years ago
(In reply to comment #16)

See comment 9 and comment 10
(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

Comment 19

7 years ago
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 ago7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.