[wix-users] Versioning for Continuous Automated Builds

[Edwin Castro]

I'd recommend you always create and release major upgrades. In my opinion
that is the easiest to manage. That said, I think I remember you saying
once that your msi package was very, very large. Deliverying a large msi
package whenever anything changes might be overkill in your case. You might
then consider dividing your package into smaller packages you can deliver
independently from each other.

Be adviced that a "patch" is a packaging option and not a type of upgrade.
For example, you can deliver a major upgrade via a regular msi package OR a
patch. I don't have practical experience with patches because I avoid them
so take the next opinion with a huge grain of salt... I conceptually think
that patches really don't mesh well with the concept of continuous
integration. A patch conceptually requires two msi packages to create a
"diff" from. In a continuous build scenario you need to be able to answer
the question of which msi package to use as the base msi package and you
can't answer that question effectively until after your first release. In
any case, you still need to create the "new" msi package for the "diff" so
I think it is always better to create major upgrade msi packages in
continuous builds and "manually" create patches when you actually need them
for a particular fix or customer. When I said "manual" above I meant
"automate the patch creation process so you can simply input the two msi
packages to 'diff' and manually invoke that script when you need it."

For versioning, the only requirement is that your ProductVersion have only
3 components less than the maximum: 255.255.65535. Note if you have a 4th
component, then the 4th component is ignored. I'd always set it to zero as
a reminder that it is always ignored.

The type of upgrade dictates if you must change ProductVersion on every
build or not. For example, if you want to build major upgrades on every
build, you must change the ProductVersion on "every" build but you really
have two options.

Option 1: always change ProductVersion. This allows you to test major
upgrades even from unreleased continuous builds in development. A very
useful tool but you do use up your available version numbers so that could
be a problem if you have a lot of continuous builds between releases.

Option 2: change ProductVersion between releases. This allows you to keep
things simple as you can just keep the ProductVersion hardcoded and change
it only at the beginning of a new release. The downside is you can only
test major upgrades between a previous release and the current continuous
build since the ProductVersion is not changing from continuous build to
continuous build.

We follow option 1 and we pass in our versioning information through
DefineConstants so the version information is available as preprocessor
variables. Let me know if you choose option 1 and I can provide more
details if you need help.

--
Edwin G. Castro


On Tue, May 29, 2018, 06:15 Ven H via wix-users <
wix-users at lists.wixtoolset.org> wrote:

> We have a requirement to generate MSI for automated builds. So, whenever
> code check-ins happen in SCM (this will also involve changes in Database
> scripts which have to be executed, IIS changes, registry changes, GAC
> changes, COM registration  etc. in addition to files), Jenkins will trigger
> a job at regular intervals by polling for changes in SCM. When this job
> runs, it has to create MSI. I have a couple of questions related to this.
>
> 1. Should I create a Patch or a Major Upgrade or a Minor Upgrade? Honestly,
> I am not sure how to create a Minor Upgrade though.
>
> 2. How should I manage versions in this case?
>
> Please help with your inputs.
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>