An interesting point. What I would advise is disregard the advice from the help files as it doesn't suit your requirements.

If you put applications under a single header interestingly enough they do not get conflict managed against each other. In my view the applications that you would be considering to put under a single header would be the same app new release.

Therefore they are the most likely applications to have conflict with each other as theres a good chance they share files / file locations across each version of the package.

You can find in the doco that packages under the same header don't get managed, you can also prove it pretty easily. (I think Wise dropped the ball on this one).

I would recommend you use a new header for each application regardless if they are the same family (assuming you want them all to play nicely together).

As for the revision control, I have used it and found that many of the packagers struggled with the concept and didnt find it anywhere near the quality you would get from a fully fledged revision control suite such as TFS or similar. It basically keeps a copy of the MSI in the revision folder allowing you to easily roll back to each one. Its a nice feature you would need to monitor its use pretty well to ensure its getting used properly. Could be done better than it is whether its worth the effort to use its debateable.

As for upgrades, you need to match component data between Package A and Package B (can't be done with single header). Upgrade Sync is another contender to look at. Also keeping track of the sequence of your FindRelatedProducts and RemoveExistingProducts. If you intend to keep these far apart its
"mandatory" to run CMDB and Upgrade Sync if you want working packages after your upgrades.

I would also recommend the use of the distribution option during import, perhaps worth investigating INI import methods.

You can find alot more detail on Wise imports, how to use SMDB, how distribution actually works on my blog.

http://johnmcfadyen.spaces.live.com 

happy reading.

Thanks for the comments John. For upgrades, I've definately have a task dedicated to running upgrade sync and verifying proper upgrade codes, etc. I do not currently have running conflict manager incorporated into that process since I was stuggling with how to layout the projects/packages. I'll look into the option of using INI import methods. As long as you can disable the distribution feature through INIs, that may be an option. The distribute to sharepoint feature is not something that will fit into our requirements.

yes it is possible to disable the distribution option, however I am not so sure thats what I would do.

The distribution option add's a lot of functionality to conflict management. again this is explained in my blog if you want to go into more detail, plenty of screen shots and detail on why / how it should be used

including the stupid things it does which are quite annoying

I've gone back and re-read your blog post about conflict management. You reinforced my understanding of the workings of the distribution option and how it relates to conflict management. My biggest issue with the distribution option is the changing of the source paths within the WSI itself. This would present a huge challenge when updating packages with new files.

Perhaps this is where my process/thinking differs from the norm, but the way I was planning on handling updates of Windows Installer packages is the following. One full source directory would be maintained for each application under the project directory. This directory would contain the full set of files and is where the MSI Source paths would point (relative). When an update to an existing (in-house developed) application would come through, which happens every 1-3 months on average, I would place the updated files into the source directory, reopen the WSI, modifiy the version, package code, etc, and then recompile the MSI pulling in the new files. I would then run through the Upgrade Sync process to verify I didn't miss anything. Whether a minor or major upgrade was used would be determined by the changes being made.

Using the distribution option would break my method above, since the source files would be scattered among 000,001 directories instead of under the project folder. Maybe my methodolgy for handling application updates is flawed, hence my confusion around the best was to utilize Software Manage/Conflict Management.

Thank you for your feedback John. This was exactly the type of advice I was looking for. I couldn't piece together in my head how these different tools fit together. It seems as though, they don't exactly fit together that smoothly. I will investigate this further, but I have a feeling my initial instinct of not using some of these features will win out.

what type of environment are you in ?

SDLC software dev

or

Corporate enterprise deployment (repacking scenario)

I am one of a couple packagers for our enterprise. Between home grown software and off the shelf software, we handle the packaging requirements of over 500 applications.