|
#1
|
|||
|
|||
|
rolling back
Is it possible to perform a rollback during a post-patch step, after the patch is applied? Say I want to do something like register activeX controls after the patch is applied, and if registering one of them fails, how do I rollback to the previous version?
|
|
#2
|
||||
|
||||
|
Do you want to rollback the entire patch, or only the activex files?
If it's the individual files, you could do it directly using actions, e.g. File.Install.
__________________
--[[ Indigo Rose Software Developer ]] |
|
#3
|
|||
|
|||
|
Quote:
Thanks |
|
#4
|
||||
|
||||
|
There is no programmatic way to force a rollback at this point, but I've added it to our list of suggestions (REF: 16976).
__________________
--[[ Indigo Rose Software Developer ]] |
|
#5
|
|||
|
|||
|
In order to support rollback capabilities for a patch that installs correctly, ie no errors in the patch process itself, but maybe the patch hadn't been fully tested and there are functional issues that would cause the need to rollback to the previous version.
Assume that a patch to take version 1.5 is applied to make the verison 1.6. Could we not reverse the patch from and to so as to create a patch from 1.6 to 1.5 and have essentially a rollback? Is there anything in VP3 that would cause this strategy not to work? |
|
#6
|
||||
|
||||
|
Quote:
You wouldn't be able to have both 1.5 and 1.6 as user-selectable targets in a single full-history patch -- so, you couldn't roll back from 1.6 to 1.5 using the same patch file that was used to go from 1.5 to 1.6. But you could easily make a separate "rollback" patch that patches 1.6 to 1.5. (In fact you could make a rollback patch to handle 1.6 to 1.5 and also handle 1.4 to 1.5, 1.3 to 1.5, and so on.) All you have to do to make your rollback patch is change the order of the version tabs, so that 1.5 comes after 1.6. VP uses the order of the version tabs to indicate newness -- by default it assumes the rightmost tab is the latest version. The actual version numbers don't matter -- they're just labels for the versions. If you're building full-history patches, you can keep the "bad" 1.6 in the history if you want...just rename its version tab (and perhaps also the source folder) so you don't confuse it with the version tab for the "good" 1.6 that you'll add later. Nice thinking btw, johnbrock. Doing the "rollback" as a patch from 1.6 to 1.5 is a really elegant solution.
__________________
--[[ Indigo Rose Software Developer ]] |
![]() |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Back Forward buttons | Carl | AutoPlay Media Studio 5.0 | 2 | 10-24-2007 05:44 AM |
| Back in the Saddle | dulux1309 | AutoPlay Media Studio 5.0 | 0 | 08-05-2004 04:42 PM |
| Move back screens from after install | toad32 | Setup Factory 6.0 | 1 | 08-14-2003 10:16 AM |
| back to original url in a webbrowser object | yosik | AutoPlay Media Studio 4.0 | 5 | 04-08-2003 04:17 PM |
| Can the BACK button have a history? | jsdunlap | AutoPlay Menu Studio 3.0 | 2 | 08-07-2001 05:00 PM |
All times are GMT -6. The time now is 02:36 AM.









Linear Mode

