I have an installer for Wix which installs the program to be version I have successfully made patches to achieve the following upgrading:
1.0.0 -> 1.0.1
1.0.0 -> 1.0.2
1.0.1 -> 1.0.2
This works I've had to make new .msp files from 1.0.0 to the target build number each time. So from my understanding how the patching works behind the scenes, is that if I had initially a patch from 1.0.0 to 1.0.1 then I created a new on to go from 1.0.0 to 1.0.2, if I were to run the new patch, the old patch would be uninstalled and the new one would replace it.
If my understanding is correct then this means that patch files would continue to increase in size the more you change code, so I would like a solution to counter this, where at some point I would increment the minor version, and start the patching process over.
For example I would like to do this:
1.0.0 -> 1.0.12 could be handle with patch1.msp. Then I create a patch2.msp which would start creating patches based off of version 1.0.12. An example upgrade path might then look like:
1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x
Is there any way to accomplish this? Or would I need to reinstall with a .msi file and continue to patch from there?
First, installing a superseding MSP does not remove superseded MSPs. The superseded MSP is simply marked as superseded (inactive). Should you later remove the superseding MSP, the previously superseded MSP is reactivated.
In order to remove MSPs, you need to use the older obsolescence method, but I really don't recommend that. Not only is it difficult to manage, it also means that, for example, if you fixed a security bug in a previous patch that was removed, when the newer obsolescing patch is removed the security hole is unpatched. That's the beautify of supersedence, which has been around since MSI 3.0.
To your question, though, I don't recommend it. It's best that MSPs target the baseline. Yes, they could potentially get a little bigger, but only if you're adding content. If newer versions are just updating sets of files or other resources, an MSP targeting a single MSI should never grow larger than the base MSI (well, MSI + external CABs, since CABs are embedded in the MSPs and always should be). See https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/ for more about small update MSPs, and https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/ for how to support targeting a single baseline with minor update MSPs.
It is possible, though. You need to save the upgrade MSIs when building each patch, so when you create your 1.0.1 MSI to effectively diff against 1.0.0 to build your MSP, then when you build your next MSP you need to diff 1.0.1 against 1.0.2. These MSPs must be minor update MSPs, though. That means that the ProductVersion property is included in the patch authoring transform; otherwise, the MSI 1.0.0 + MSP 1.0.1 view won't change the ProductVersion, so MSP 1.0.2 would never be applicable. You should start to see where this gets difficult to maintain for you (not to mention forces the customer to have to install every previous version MSP, which is not a great experience for them either if they are just starting out from your RTM).
In summation, keep it easy for your customers. Just target the same baseline using the MinorUpdateTargetRTM property in the MsiPatchMetadata table of the MSP itself.