rolling back

[rjfioravanti]

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?

[Lorne]

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.

[rjfioravanti]

Do you want to rollback the entire patch, or only the activex files?

I want to rollback the entire patch

Thanks

[Lorne]

There is no programmatic way to force a rollback at this point, but I've added it to our list of suggestions (REF: 16976).

[johnbrock]

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?

[Lorne]

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?

Yep, that should work fine, assuming you build the rollback as a separate patch.

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.

[AaronK]

Hi,
It's been a few years since this thread was started, but I was wondering if this is still the recommended way of rolling back (uninstalling) a patch made by Visual Patch. The stated method would suit us fine, but I was wondering if there have been any advancements in the time intervening toward making this a more automated process. I wasn't able to find anything in the documentation about it, so I don't really expect anything, but I'd like to check before I make any recommendations about this software.
Thank you!

[Lorne]

It depends on the reasons for rolling back; if you're doing incremental patches (1.1 to 1.2, followed by 1.2 to 1.3, etc.) it's pretty easy to also make an incremental patch to go in the opposite direction.

The biggest difficulty arises if you need to reverse custom actions that were performed by the patch, which is the part that would make automated rollback difficult to implement.