InstallShield MSI Tools and the Licenses Agreements - Hotdogs and Hotdog buns

[DLee65]

Ok, when you go to buy a package of hotdogs you get a dozen hotdogs usually. When you buy the rolls you get 8 rolls typically. So what does this have to do with the new MSI tools.

Well, if you do have a license to Premier you can install the Standalone build on up to 10 build machines for each Premier license. With InstallShield 2009, Acresso included some new nifty tools such as InstallShield MSI Diff which can be integrated with your code control software (e.g., Accurev, Visual Source Safe, etc). HOWEVER, the EULA specifically states that you can only have the tools on up to 5 machines. So if you happen to have one copy of Premier and you have 10 build machines (go with me on this ... it is hypothetical) and you want to use the new InstallShield MSI Diff tool with your source control system then you would need two Premier licenses to cover the 10 build machines.

Wow! Talk about Hot Dogs and Hot Dog rolls! Acresso doesn't own stock in the Hot Dog roll business does it? 😄

[Christopher_Pai]

We buy the hebrew national hotdogs that only come 7 to a pack. Now inevitably I always drop or burn food. For the hot dogs, well we follow the 10 second rule. For the buns, well I like to teach my girls to feed the brids. 🙂

BTW, you've had so many posts lately.... have you ever thought about blogging? I'm always accepting new members on my team.

http://blog.deploymentengineering.com/2007/12/bloggers-wanted.html

[DLee65]

Well this week and next week are devoted primarily to reviewing IS2009 so that is why I am writing so much more.

I am just now reading through the entire release notes. This is probably the first time that I have done this and I have been at this since 2000. I must admit I am glad to see several changes.

I might take you up on your blogging offer. I will contact you there and let you know. The problem is that I usually go in spurts ... 🙂 I have a week where I monitor the forum here regularly and then life gets busy again and I am heads down and a coding mutant!

[Stefan_Krueger]

In my understanding the build licenses are mainly intended for machines that perform unattended nightly builds. MSI Diff is a UI tool which makes sense for developers, testers, integration/configuration work, bt not for unattended build scripts. So it seems to make sense to have more build licenses than MSI Diff licenses.

[#5]

Stefan is correct.

[edit: removed 2nd sentence as it was answered]

[DLee65]

Stefan,

We have a tiered build system. Development promotes issues into Stream #1 and in this case the use is as you described. I would introduce a change and promote it into the development stream; in this process I would use the UI to verify the differences and document the changes in the bug tracking system.

An automated build system then is activated and builds the project and setup for the project. If this passes then the issue gets setup for code review. Then another developer will be assigned to review the code and may use the InstallShield MSI diff tool to help verify the changes. Here again, your use case is correct. If the code passes review and the Stream #1 build looks good, then the issue gets promoted to Stream #2. This is built and sent onto QA for testing. Once it passes the QA tests then the issue gets tagged as complete.

I was thinking that we would use command line options for the MSI Diff tool in the final stage to evaluate the changes for promote to the final stream, but now that I think of it, we actually use the bug tracking software for this. All the tickets that have been tagged complete actually get promoted. So I was incorrect in my original thinking that I would need to have the tool to check if something needs to be promoted or not.

I guess I ended up fishing for 'red-herring' 😮

Thanks for setting me straight. 😄