[release/3.1] Generate non-stable version for installer

[wtgodbe]

Generate a non-stable ProductVersion for installers so that updates can occur between installers in the same Major.Minor.Patch band (e.g. previewN to previewN+1)

https://dev.azure.com/dnceng/internal/_build/results?buildId=821089&view=results

[joeloff]

I don't think this is what's used. For 3.1, we should fix this:

<GenerateGuid NamespaceGuid="$(NamespaceGuid)" Values="$(AspNetCoreMajorVersion).$(AspNetCoreMinorVersion);$(Platform)">
  <Output TaskParameter="Guid" PropertyName="BundleUpgradeCode" />
</GenerateGuid>

For example, if we're building the following bundles, we want something like this (I kept the bundle version to 3 parts)

3.1.44228       x86   46e465cf-b871-370b-972b-07484f8dbb0a
3.1.48943       x86   46e465cf-b871-370b-972b-07484f8dbb0a
3.1.2357        x64   e9cb5174-b032-3f09-8a6c-a4513eaf62e8
3.1.60141       x64   e9cb5174-b032-3f09-8a6c-a4513eaf62e8

[dougbu]

Just curious: What sets $(FileRevisionVersion)❔

And, a nit if we need this change:

Suggested change

	<Version>$(AspNetCoreMajorVersion).$(AspNetCoreMinorVersion).$(AspNetCorePatchVersion).$(FileRevisionVersion)</Version>
	<Version>$(AspNetCoreMajorMinorVersion).$(AspNetCorePatchVersion).$(FileRevisionVersion)</Version>

[joeloff]

aspnetcore/src/Installers/Windows/Wix.targets

Line 7 in 0250c22

<_FileRevisionVersion>$(VersionSuffixDateStamp)</_FileRevisionVersion>

[wtgodbe]

Builds of this branch: https://dev.azure.com/dnceng/internal/_build/results?buildId=821646&view=results
https://dev.azure.com/dnceng/internal/_build/results?buildId=821665&view=results

Build of this branch with patch version +1: https://dev.azure.com/dnceng/internal/_build/results?buildId=821647&view=results
https://dev.azure.com/dnceng/internal/_build/results?buildId=821666&view=results

[dougbu]

Again, WFM but @joeloff's opinion is the one that matters

[wtgodbe]

New builds w/ version+1 (last one had a packageIndex failure)

https://dev.azure.com/dnceng/internal/_build/results?buildId=823563&view=results
https://dev.azure.com/dnceng/internal/_build/results?buildId=823562&view=results

[wtgodbe]

@joeloff I pushed 1f7fb7c. This will go into 3.1.10, so we'll need to add the upgrade codes for 3.1.9 once those are available.

[joeloff]

I think this looks good. We should get a couple of test builds to look at

Maj.Min.x
Maj.Min.x+1
Maj.Min+1

and pick two random official releases and then check that downgrades are blocked, upgrades are processed.

[wtgodbe]

Builds:
3.1.9: https://dev.azure.com/dnceng/internal/_build/results?buildId=824028&view=results, https://dev.azure.com/dnceng/internal/_build/results?buildId=824029&view=results

3.1.10: https://dev.azure.com/dnceng/internal/_build/results?buildId=824039&view=results

3.2.0: https://dev.azure.com/dnceng/internal/_build/results?buildId=827443&view=results

[dougbu]

If manual tests of upgrades work, WFM

[wtgodbe]

Testing confirmed that the behavior is now correct. 3.1.10 removes 3.1.9 when installed, 3.1.9 won't install when 3.1.10 is present, and 3.2.0 installs alongside 3.1.10.

[joeloff]

Woohoo! That's great to hear @wtgodbe

[dougbu]

@Pilchie this is the PR where I meant to ask you about 3.1.10 ask or tell mode

[Pilchie]

Same - tell mode with an explicit mail should be fine.