[wix-users] Versioning for Continuous Automated Builds

Rob Mensching rob at firegiant.com
Wed May 30 09:20:32 PDT 2018

The WiX Toolset itself installs using Burn. Burn supports all 4 fields of the version. If you see two versions of the WiX Toolset like that, chances are the uninstall of the old version failed during upgrade.
 Short replies here. Complete answers over there: http://www.firegiant.com/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Ven H via wix-users
Sent: Wednesday, May 30, 2018 8:24 AM
To: Edwin Castro <egcastr at gmail.com>
Cc: Ven H <venh.123 at gmail.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Versioning for Continuous Automated Builds

Thanks a lot, Edwin. Appreciate all your help and support. By the way, I
had one more question. As you mentioned, I have also read that the 4th
digit in the Version gets ignored. But even in 2 different WiX versions, I
saw one as or something like that and the other one as or something like that in the Add / Remove Programs and both
versions coexist there. I am a little confused.


On Wed, May 30, 2018 at 8:23 PM, Edwin Castro <egcastr at gmail.com> wrote:

> Ven,
> I forgot last night to get on my computer and write something up. I'll set
> a reminder to do so tonight after work.
> --
> Edwin G. Castro
> On Tue, May 29, 2018, 09:36 Ven H <venh.123 at gmail.com> wrote:
>> Wow. Words of wisdom blended with experience, expertise and so much
>> humility. Thanks a ton, Edwin, for that awesome and detailed explanation. I
>> would like to take it further. When you say divide your package into
>> smaller packages, can you please provide some more details on how to
>> achieve it and how to manage manage product guids, upgrades and so on for
>> all the packages together and what will be the points to keep in mind. If
>> you could please provide some more details on how to go about, I would like
>> to take it further.
>> On the next part, I personally prefer Option 1 and I will tell my
>> customer to go with that. So, can you please provide some more details
>> about that as well?
>> Regards,
>> Venkatesh
>> On Tue, May 29, 2018 at 7:31 PM, Edwin Castro <egcastr at gmail.com> wrote:
>>> 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/

WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

More information about the wix-users mailing list