View Full Version : Quickpatching -- a colossal maintenance nightmare??

11-07-2005, 09:12 AM
I would imagine everyone who has ever released more than one update to their product has encountered this, yet I can't find any discussion on the topic.

So you release your first version as a new install package. You then release a quickpatch updating to the next version. A few versions down the road, do you ever create a new install package or is it just quickpatching from now on?

It seems a bit silly to send a new customer an install package with 15 quickpatches. But is this the norm?

To do otherwise seems like a collossal undertaking. For every new install package, you quickpatch that msi... and then quickpatch that quickpatch over and over from then on; for a new install package, you'd have to quickpatch the new package, while also quickpatching the original install package's quickpatch. After another new install package, you're creating 3 different quickpatch projects. It seems like this would exponentially grow into a nightmare maintenance job. 20 versions down the road, I don't want to be maintaining 20 different chains of quickpatches!

I'm sure I have a gross misunderstanding, but this logic is based on the fact that when you create a quickpatch, you have to target either an .msi or existing quickpatch.

Please help!

11-07-2005, 12:08 PM
I think the normal case is to stop patching a previous major revision after you release either the next major revision, or the one after that. For example it seems unlikely that a single patch would be able to handle both patching 1.1.12 and 1.2.3, to turn them into 1.1.13 and 1.2.4 respectively. And thus you would build them separately.

If you are interested in more flexibility in the patching and upgrade behavior, you may want to consider the InstallShield 11 Professional product line. In that version you can create minor upgrades, and turn them into patches. The minor upgrade would serve as a fresh install or upgrade, and any patches created from it would be the download-saving version you could give to customers with existing installs.

The patches can be built to upgrade an arbitrary set of existing versions, although again a single patch can only take you to a single resulting version of your files. Tying this to the previous example, this would let you turn both 1.1.12 and 1.2.3 into 1.2.4 if you so chose (although depending on the changes between 1.1.x and 1.2.x, there may be a noticeable size overhead).

11-07-2005, 03:58 PM

Thanks for the insight and info about InstallShield Professional. It certainly sounds more flexible! Our distribution requirements are pretty basic though. I think your advice on how to hande major revisions may be what I was looking for.

So if I'm understanding it correctly, a major revision is generally the time to consolidate customers on a quickpatch chain and those about to receive a new install.

For example, 1.0.0 is released and over time, quickpatches take it to 1.2.4. Any new customers at this point receive the base 1.0.0 and the 1.2.4 quickpatch. Around the time of a major revision, we would then release a 2.0.0 "upgrade" that contains a full install as well as updates existing installations. Now everyone is at 2.0.0 and the quickpatching starts again until the next major revision.

Please correct me if I'm wrong; otherwise, thanks for the help! :)


11-08-2005, 11:24 AM
The only inaccuracy I'm certain of is the last part, where you talk about an upgrade containing both full install and "updates". This is true of a "minor upgrade" which has the size of a full install, but in an upgrade scenario installs like a patch. A "major upgrade" will also be the size of a full install, but will perform an automatic uninstall followed by a full intall. You can only make patches and "major upgrades" in Express. Ideally there is little important difference to the end user.