This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Help with Upgrade Strategy/Upgrade paths list unweildy
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
11:29 AM
Help with Upgrade Strategy/Upgrade paths list unweildy
Up to now, we had one product version number line 2.0.n that we continually published bug fix and new features to.
Our install was small, and we did not want to deal with patches and all the complications we just wanted the installer to remove the previous version and install the new version and hence we modified the product code and upgrade code for each new 2.0.n update and added a upgrade path for each subsequent version, this is what support told us to do and it worked great.
Now we have this long line of upgrade paths over the last couple of years and it is getting unwieldy (we have had over 60 upgrades).
The problem is becoming untenable, now we are introducing a new version of the product 3.0.n line and intend to keep the 2.0.n line open for bug fixes only and the 3.0.n line for new features and bug fixes for that line. The 2.0.n line will not be closing any time soon and will get the occasional bug fix release.
In all cases we want the old version to be removed and the new version to be installed regardless.
But keeping a list of upgrade paths for both lines in the 3.0.n line will become impossible to maintain, because the lines are separately maintained.
There has to be a better way, do you guys know of one?
Thanx
Bodger
Our install was small, and we did not want to deal with patches and all the complications we just wanted the installer to remove the previous version and install the new version and hence we modified the product code and upgrade code for each new 2.0.n update and added a upgrade path for each subsequent version, this is what support told us to do and it worked great.
Now we have this long line of upgrade paths over the last couple of years and it is getting unwieldy (we have had over 60 upgrades).
The problem is becoming untenable, now we are introducing a new version of the product 3.0.n line and intend to keep the 2.0.n line open for bug fixes only and the 3.0.n line for new features and bug fixes for that line. The 2.0.n line will not be closing any time soon and will get the occasional bug fix release.
In all cases we want the old version to be removed and the new version to be installed regardless.
But keeping a list of upgrade paths for both lines in the 3.0.n line will become impossible to maintain, because the lines are separately maintained.
There has to be a better way, do you guys know of one?
Thanx
Bodger
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
02:57 PM
Sorry, I don't understand why did you change the Upgrade Code each time? You just have to modify the Product Code and leave only One Upgrade path with One upgrade code with Versions range from Min: 2.0.1 to Max: 2.0.60
so you have only one upgrade path in the list...
If there was no reason for this and you did it by mistake, you can stop extending your list and use the v2.0.60's Upgrade path's Upgrade Code for all the future versions (at least for 2.0.x - you may want to use the different Upgrade Code for 3.x if you want to allow to install v2 and v3 at the same time, but block downgrades e.g. 3.0.2 to 3.0.1 or 2.0.2 to 2.0.1.
so you have only one upgrade path in the list...
If there was no reason for this and you did it by mistake, you can stop extending your list and use the v2.0.60's Upgrade path's Upgrade Code for all the future versions (at least for 2.0.x - you may want to use the different Upgrade Code for 3.x if you want to allow to install v2 and v3 at the same time, but block downgrades e.g. 3.0.2 to 3.0.1 or 2.0.2 to 2.0.1.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
03:12 PM
>Sorry, I don't understand why did you change the Upgrade Code each time?
Support told me to, I do not understand it regardless.
Let me see if I understand you correctly. If for the 2.0.n line, I stop changing the upgrade code and continue to change the product code and set the max version to some high value, set a different upgrade code for the 3.0.n line then all my 3.0.n installs should always uninstall a 2.0.n line?
If I understand you correctly then thats is what I need, Thank you.
Bodger
Support told me to, I do not understand it regardless.
Let me see if I understand you correctly. If for the 2.0.n line, I stop changing the upgrade code and continue to change the product code and set the max version to some high value, set a different upgrade code for the 3.0.n line then all my 3.0.n installs should always uninstall a 2.0.n line?
If I understand you correctly then thats is what I need, Thank you.
Bodger
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
03:22 PM
yes, this should work. but please TEST it, because if support told you to change Upgrade Codes, maybe you told them some additional setup specifications... anyway i don't know for what reason this may be helpful...
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)