I have been asked to look into changing our release methodology for our MSI builds.
Since the company has started they have always released major upgrades and their build and release structure reflects that methodology.
Now project managers would like to offer both a major upgrade packages that include all prerequisites for new installations and upgrades to older installations; as well as a "full upgrade msi" that includes all full binaries but no prerequisites. This would overwrite existing binaries and would require that the application be already installed.
The problem is that our current process has not kept uncompressed setups for the releases and so building a true 'patch' is not possible for current releases. We have not even kept the msi file, we have always just published the final EXE package. And most of these packages are Wise Installer packages which do not allow for uncompressing the contents and getting the msi file.
Am I able to accomplish something like this in a current configuration? How do I handle things like the upgrade table where I need to specify min version numbers? For example for a major upgrade build, the min version numbers are far more expansive than for a 'full upgrade msi'. The full upgrade msi can only go back to when we switched to SQL 2012.
I guess I could programmatically alter the table using the API before compiling the full upgrade msi. But that seems like more work than should be necessary to do this. Perhaps I am overthinking this. :p
Since the company has started they have always released major upgrades and their build and release structure reflects that methodology.
Now project managers would like to offer both a major upgrade packages that include all prerequisites for new installations and upgrades to older installations; as well as a "full upgrade msi" that includes all full binaries but no prerequisites. This would overwrite existing binaries and would require that the application be already installed.
The problem is that our current process has not kept uncompressed setups for the releases and so building a true 'patch' is not possible for current releases. We have not even kept the msi file, we have always just published the final EXE package. And most of these packages are Wise Installer packages which do not allow for uncompressing the contents and getting the msi file.
Am I able to accomplish something like this in a current configuration? How do I handle things like the upgrade table where I need to specify min version numbers? For example for a major upgrade build, the min version numbers are far more expansive than for a 'full upgrade msi'. The full upgrade msi can only go back to when we switched to SQL 2012.
I guess I could programmatically alter the table using the API before compiling the full upgrade msi. But that seems like more work than should be necessary to do this. Perhaps I am overthinking this. :p