Closed Bug 101801 Opened 23 years ago Closed 16 years ago

Autogenerate upGradeClean()

Categories

(SeaMonkey :: Installer, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: curt, Unassigned)

References

Details

Need to add a deleteThisFile entry for every obsolete file that might need to be removed during an upgrade installation. Currently this is being done by hand (see bug #94108). There should be a way to automatically compare two installation and generate this function from the diff.
Status: NEW → ASSIGNED
grega - is this a required fix for AOL TW, or does the Bug 94108 work for now.
Keywords: nsbranch
Not required for 6.2
waiting for JPM's team to verify. I believe we want this for 6.2 but I'll let JPM give us the word. Keep on the radar for today. Marking nsenterprise+
Keywords: nsenterprise+
Note that 94108 is only for windows, but solves the problem for upgrades using the native install. If people are going to be using XPInstall directly to upgrade (like the SmartUpdate site, or the proposed AutoUpdate feature) then you'd have to fix the ren8dot3 problem for win9x machines, and do the equivalent to 94108 for Mac and Linux.
How much work is "fix the ren8dot3 problem for win9x machines, and do the equivalent to 94108 for Mac and Linux"? If this is a lot of work is there a work around for TW? They will deploy 6.2 to approx. 37,000 desktops. How can we get them to 6.3 and keep costs down? Thanks!
There seems to be a misunderstanding about this bug. This bug is simply referring to the fact that right now, we have to manually figure out what files are obsolete between 6.00 all to way to the latest builds (6.2). This bug is simply indicating that this process needs to be automated. This is not a requirement for any particular release. It would just make things easier if we didn't have to do this by hand right before every release.
QA Contact: bugzilla → ktrina
given ssu last comments, i am gonna PDT- this one. grega - pls let us know, why this is a nsenterprise+.
Whiteboard: PDT-
Keywords: nsbeta1
Blocks: 104166
Keywords: nsbeta1
nsenterprise- added
Blocks: 107065
Keywords: nsbranch
Target Milestone: --- → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
This won't stop us from shipping, though it'd be nice
Keywords: nsbeta1nsbeta1-
removing PDT grafitti.
Whiteboard: PDT-
Resetting milestone of all nsbeta1-bugs, only nsbeta1+ bugs should have a target milestone.
Target Milestone: mozilla1.0 → ---
Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are niminated, but not yet plussed.
are we gonna do something like stated in this bug. Otherwise lets close it and do the cleanup like now, manually...
This is minused and now futured. We don't want to close it because it needs to be done. There just doesn't seem to be time now. We are continuing to do the manual cleanups as they arise. Is there one in particular that seems to be getting ignored?
Target Milestone: --- → Future
Product: Browser → Seamonkey
Assignee: curt → nobody
Status: ASSIGNED → NEW
QA Contact: ktrina → general
Target Milestone: Future → ---
Seamonkey and Firefox are using a new NSIS based installer. resolving this old bug, please reopen if you still get this with the new installer
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.