[wix-users] Versioning for Continuous Automated Builds

[Edwin Castro]

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/
>>>
>>
>