[wix-users] Updates with Major.Minor.Build.Revision needed

[Edwin Castro]

I just realized that Sampat Magi is not the original poster, Steffen
Vogel. That probably explains why ProductVersion seemed to have 4
quads and 3 quads. I got confused on who I was responding to and whom
they were responding to.

The reasons I mentioned my previous email are still valid and I hope
to convince the original poster to ensure the first three quads for
ProductVersion change so that their major upgrades work as expected.

--
Edwin G. Castro


On Fri, Aug 12, 2016 at 11:54 AM, Edwin Castro <egcastr at gmail.com> wrote:
> You've completely lost me.
>
> On Fri, Aug 12, 2016 at 7:50 AM, sampat magi <ssmcs060 at gmail.com> wrote:
>> Ahh!! Something is bringing miscommunication!!!
>
> Agreed!
>
>> I am thinking on the second part of the original question, which goes like
>> this,
>>
>> Now I am asking you to please help me find a good solution in which the
>> installer uses all (Major.Minor.Build.Revision) for version comparison,
>
> This sounds like your ProductVersion has four quads:
>
> ProductVersion = Major.Minor.Build.Revision
>
> This format is accepted by the Windows Installer *BUT* ProductVersion
> comparisons will ignore the fourth quad. You cannot change this
> behavior.
>
> The Upgrade table performs this comparison for you and can be used to
> set a property to tell you if you're trying to perform a downgrade.
> The <MajorUpgrade/> element will automatically configure the Upgrade
> table to perform this check for you.
>
>> which prevents downgrades with a specific error message and tells me what's
>> going on via properties or something so I can schedule my actions depending
>> on that.
>
> The <MajorUpgrade/> element will produce a LauchCondition that
> prevents downgrades by inspecting the property created by the Upgrade
> table when a downgrade is detected. This uses the ProductVersion
> comparison that Windows Installer performs which only compares the
> first three quads.
>
> So you get this behavior for free when you follow the Windows Installer rules.
>
> You seem to want to ignore the automatic downgrade protection offered
> by <MajorUpgrade/> because it only compares the first three quads of
> ProductVersion. You want to perform your own comparison so that you
> can compare all four quads and schedule your actions depending on the
> results of your own comparison...
>
> Creating such a custom action to perform that comparison is doable and
> fairly trivial. You get a property, parse the property, compare, set
> property based on comparison result. Custom actions really do not get
> easier than that.
>
> BUT you only need this comparison IF, AND ONLY IF, you have a scenario
> where the first three quads are the same. All other scenarios are
> automatically captured by <MajorUpgrade/>.
>
> When the first three quads are the same, you are no longer performing
> a major upgrade. In fact it is unclear what you are actually doing.
>
> Take a look at the table describing the different types of updates at
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa370579.aspx
>
> The "Changed" value for the ProductVersion column corresponds to the
> three-quad comparison done by Windows Installer. This is the behavior
> you cannot change.
>
> You've changed the ProductCode (otherwise it wasn't going to be a
> major upgrade anyway) but you have NOT changed the ProductVersion.
> This row does not exist on the different types of updates table. The
> reason the type of update matters is that it dictates which kinds of
> changes are allowed.
>
> You keep asking about detecting the "downgrade" scenario. That's
> wonderful but what about the "upgrade" scenario? When you're upgrading
> from 1.2.3.4 to 1.2.3.5? Those are both the same ProductVersion to the
> Windows Installer. I believe the Windows Installer tries to
> reconfigure your product even though the ProductCode changed! You're
> very likely not going to get the behavior you want and/or expect
> mostly because you're in undefined space.
>
>> Or is there any better idea???
>
> Yes. The better idea is make sure ProductVersion will always have a
> proper three-quad change between major upgrades. There are many
> strategies on how to ensure a proper three-quad change between major
> upgrades BUT they all require that the first three quads change
> because the four quad is ignored if it exists. You can't change this.
>
>> My thought was to have type 19 CA to display appropriate downgrade error
>> message using version read from registry into a property!!
>
> Sure, using a type 19 CA to display an error message is an easy way to
> communicate with your user. A LaunchCondition is properly better. But
> this is beside the point. The "downgrade" case is not really of
> concern because you're trying to avoid it (as you should). The problem
> is with the opposite case where you are trying to upgrade even though
> the Windows Installer does not recognize the scenario as a valid
> upgrade.
>
>> Yes, we should Windows Installer rules and standards to avoid additional
>> overhead!!!
>
> This is not about overhead. It is about correctness, reliability, and
> reproducibility. You're not going to get any of those if you allow
> upgrades when only the fourth quad has increased.
>
>> We differentiate our products patches with 3 version fields.
>
> ... huh!? ... Are you using four quads or three? Which is it?
>
> What do you mean by product patches?
>
> Are you saying you're creating MSI with four quad ProductVersion but
> then trying to "patch" with MSP that only has three quad
> ProductVersion?
>
> Or are you saying ProductVersion always has three quad ProductVersion
> regardless of whether you've created an MSI or MSP?
>
> Or are you trying to say something else?
>
> You should note that you can package small updates, minor upgrades,
> and major upgrades in MSP and/or MSI packages. The extension does NOT
> determine whether you're installing a "patch" or an "upgrade". The
> different types of updates table linked above determines the type of
> update regardless of extension.
>
> I'll say it again because it is important. The package extension does
> not matter. PackageCode, ProductCode, and ProductVersion are what
> matter in determining what type of update will occur.
>
> Hopefully, I've done a better job giving you a taste for why you're
> headed down the wrong path. The problem isn't performing the
> comparison or doing something with the knowledge that the fourth quad
> in ProductVersion decreased ("downgrade"). Those things are trivial.
> The problem is what happens when you allow an "update" when the fourth
> quad in ProductVersion increased. The Windows Installer will not
> detect that scenario as a major upgrade and you will not get what you
> want or expect. It will not be correct. It will not be reliable. It
> will not be reproducible.
>
> But if you think you know better (and my you I mean your boss), then
> feel free to do what you want. You were warned. Good luck!
>
> --
> Edwin G. Castro