[wix-users] Versioning for Continuous Automated Builds

[Ven H]

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