3 replies to this topic

[thompsonson]

I'm automating the build of our installations and i have been thinking about generating a new product code every time it is built for test.
Each time it is built it will contain (slightly) different binaries and be a new version if only in build.
Want i'm concerned about it that by changing the product code I will cause a problem for later upgrades\patchs. From what I have read it is the upgrade code property that is key for continuity.
(The confusing bit for me is if the product code can change why have a package code... )
Anyway, thanks for reading,
matt

[KathyMorey]

As I understand it, the Package Code is intended to differentiate between builds of the same product. The Product Code is intended to differentiate between different products, or between major versions of the same product.

The upgrade code allows you to relate products for removal during a major upgrade.

I don't think you need to go so far as to change your Product Code for every test build, unless you are counting on automatic removal of the old version by the new one when it is installed.

We usually change only the Package Code for test builds; we reserve changing the Product Code for when we prepare a major upgrade of a previous version.

HTH

Kathy Morey
Installation Developer
SER Solutions, Inc.
kathy.morey@ser.com

[Glytzhkof]

Yes, this is the concept:

Upgrade Code: Identify a family of related products
Product Code: Identify a specific product
Package Code: Identify a specific setup file. This property should always change for all builds. Two setups with the same package code is treated as the same setup regardless of content.

Pushing up the product version and changing the package code should be sufficient. However, I always use major upgrades during testing since I want to uninstall the existing installation before installing the new one. I find this more robust, but this is just a personal preference.

[luke_s]

I also agree with Glytzhkof, I would use a major upgrade