[wix-users] Versioning for Continuous Automated Builds

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 3.11.0.1731 or something like that and the other one as
3.11.1.1234 or something like that in the Add / Remove Programs and both
versions coexist there. I am a little confused.

Regards,
Venkatesh

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/