Currently, the installer makes no attempt to upgrade an existing install. You can install to a new directory, or you can delete the old install and then re-install with the new version. We need to support the ability to upgrade. During an upgrade, the existing installed components need to be considered or the result may not be a working product. The main example would this: component A exists on the machine component B is being installed both A and B depend on component C In this case, if component A isn't installed at the same time as B & C, it probably gets broken. Information needs to be collected about what's already installed, and then this needs to feed into new dependency rules during the install. Cathleen, please do not mark confidential. I no longer depend on this internally.

Fixing CC list.

Example case: You install 5.0 browser and mail. You then upgrade to 5.1 but decide to upgrade only browser. You then run the still-present mail and probably crash due to API mismatches. Or simply won't load on windows. We can dream that we will freeze all the XPCOM interfaces, but even if we do there are tons of raw C++ linkages to the xpcom utility classes (nsCOMPtr, nsString, etc., etc.)

I'm afraid inter-dependencies between various versions of files/components will be hard to manage with the way we build our "components".

probably could be done by marking-up dependencies. I think we have "mail requires browser" type dependencies now; we could add something that says "mail requires browser and must be updated if it is" :-)

if we upgrade the browser component, we need to upgrade all other components that are already installed on users machines. changes need to be made in the wizard reassign to ssu & ccing sgehani for mac&linux wizards bug meeting 3/20

adding myself to cc list - mental bookmark

pr2 feature

Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.

Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature train. Please set to MFuture.

This missing feature is one reason for the complaints in 40708. Given our munged interface story we can crash if we leave old components behind on an upgrade, whether that's an entire package like mail or simply some superceeded component

Giving [nsbeta2+]Exception Feature status

Sean, what's the story on this one? I thought this one described our preferred mechanism to delete only specific files on upgrade that we were told not to take the time to do for PR2? Other bugs cover the "nuke from orbit" technique we are currently using for upgrades. Shouldn't this bug (exception feature) therefore be nsbeta2- ? Since it's currently on the books as an exception feature I need status on it and how likely it is to make 6/22 (which I assume to be 0% likely).

First thing. Selmer needs to take grammer classes. It's extremely difficult to follow his example. This bug eventually narrowed down to having the installer provide an "upgrade" feature, which means: If the user is installing ontop of previous seamonkey, upgrade the product, which includes performing necessary file and directory deletion/move. There was a proposed solution to do the exact procedure listed above, but was shot down for nsbeta2 by the pdt team due to time constraints. A more simple, but archaic "upgrade" was agreed on: Detect if the user is installing ontop of a previous seamonkey build and offer them two choices: 1) delete installation directory before continuing with installation. 2) choose different installation directory. The archaic "upgrade" is already being implemented. This bug should now be marked as nsbeta2-.

Note that this bug really describes the issue of not allowing the user to upgrade only some of their previously installed components, not so much the issue of deleting obsolete files that might cause problems. The "nuke from orbit" strategy used to solve the latter happens to make the former go away too. It's not a very satisfactory solution for either which is why this bug is left open, but we don't have the bandwidth to implement the required functionality. Removing nsbeta2+ for reconsideration.

another confusing scenario related to this: If you install Netscape 6 - typical, then decide you want to install Java, when you go back to Installer- choose custom and next- Installer prompts you to delete current path [delete] or go [back] and choose new path. Since you do not want to delete the current installation- this is confusing. You can however, choose [delete], deselect all components except Java (and Browser which is always installed) and the installation will take place - in effect copying over files in the previous installation directory- I don't know yet what files in the Installation directory may be affected. This directory contained an installation done on Fri (6/16) and files in the directory now contain 6/18 (build) dates and 6/19 (installation) dates.

michaell, can you live without this for Netscape 6? :-)

M16 has been out for a while now, these bugs target milestones need to be updated.

Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix to make a call on this bug.

Info for PDT: http://puma/xpinstall/UpgradeOptions.html (apologies that the doc isn't external: can post if needed) We have currently gone with Option 1. This bug is about whether we should undertake the work for Option 2.

Minus the sucker. Marking nsbeta2-. Reassigning to dveditz. I agree with the nuke from orbit strategy (and rather like the terminology). We don't need to get fancy, we just need to ship.

Resetting Target Milestone as we are way past M16 can we give M18 a try, if not push father back. NSbeta3???? (is there a feature creep keyword? :)

This will get nsbeta3- but johnlar asked. Samir Gehani please export the spec. When in doubt, please export the spec. If the bug is in bugzilla then external contributors should be able to work on it. Adding helpwanted per nsbeta3-

Unsetting missed milestones to aid triage queries.

We need surgical upgrades for the next major release, cannot just blow away people's plugins

Not sure who should own this...

Reassigning to Sean for the Windows installer. Samir owns bug 34877 for the mac and linux installers.

Moz 0.8 tasks

Changing platform and OS accordingly. Also the patch will be attached to bug 66480 as part of its fix.

fixed.

Build: 2001-02-23-16-Mtrunk(WIN) This has been working for some time. Marking Verified.