Integration with Setup Factory

[jinjoid]

Is it ever likely that Visual Patch will be able to use the content of a Setup Factory installer for its versioning?

It would seem (from my limited knowledge of Visual Patch) that as a standalone product there is no real advantage to users of your installer products. If Visual Patch could take the version from a Setup Factory installer and use the files within for the differencing, the management of new build and associated patches would be much more straightforward and would help you cross sell your installation products in the same way that True Update complements Visual Patch.

It would seem that keeping historical versions of all files is mandatory for a good patching strategy. I don't do this due to the sheer amount of data I would have to store. I do however always keep historical versions of each Setup. I keep historical version of source.

I understand that using this suggested approach would be considerably slower than differencing on different folders but the convenience would far outweigh the time.

I'm hoping that you are going to tell me that I can do this already and that I haven't found that part in the manual. Please :D

Jinjoid

[jinjoid]

From the lack of replies I guess I can't use Setup Factory Installers as my differencing source. Shame.

Cheers

Jinjoid

[Lorne]

Is it ever likely that Visual Patch will be able to use the content of a Setup Factory installer for its versioning?Hmmm, that's an interesting idea. It would technically be possible, although I'm not sure if it would be as useful as you might think. (See below.)

It would seem (from my limited knowledge of Visual Patch) that as a standalone product there is no real advantage to users of your installer products.One significant advantage is that they share a common scripting language, action library, interface settings, etc. As you learn to use one tool, you also improve your skills in the other one. This also helps when switching between the two tools.

If Visual Patch could take the version from a Setup Factory installer and use the files within for the differencing, the management of new build and associated patches would be much more straightforward and would help you cross sell your installation products in the same way that True Update complements Visual Patch.Yes, I can see how that could come in handy for someone who keeps an archive of installers. Although you could achieve similar advantages just by keeping compressed archives of the install images for each version (e.g. using 7-Zip to compress your source files).

It would seem that keeping historical versions of all files is mandatory for a good patching strategy. I don't do this due to the sheer amount of data I would have to store. I do however always keep historical versions of each Setup. I keep historical version of source.In practice there is rarely a need to build patches for very old versions; there are advantages to "mothballing" old versions once the likelihood of their being encountered is significantly diminished.

If there's a 0.01% chance that someone will still have a really old version, it's probably better not to include it in your current patching pool. Instead, have them apply an older patch or sequence of patches to bring their version up to date. In many cases it might even be reasonable to expect users of such rare versions to uninstall their current version and install a "milestone" version that they can patch from.

Just because you can build a patch that will update every version you've ever released doesn't mean you need to. In most cases the best strategy is to focus your patches on the previous two or three releases, and to use milestone patches that cover a range of versions for the older ones.

Once you've created and tested these milestone patches, and are confident that you won't need to rebuild them, there's nothing stopping you from mothballing them: keep the patch executables, backup the projects, and then delete the source files for those versions.

In the extremely unlikely event that you need to rebuild those old milestone patches, you can always recompile everything from your source archive.

I understand that using this suggested approach would be considerably slower than differencing on different folders but the convenience would far outweigh the time.It's definitely an interesting suggestion -- thanks :) -- I've logged it for consideration (16638).
I'm hoping that you are going to tell me that I can do this already and that I haven't found that part in the manual. Please :DNo such luck. :) My advice would be to treat the patches just like your setups: keep the patches, and delete the source files. Use milestone patches, each covering a range a versions, instead of monolithic ones.

[jinjoid]

for the comprehensive reply. It really is very helpful.

Jinjoid