1535393 - Fill in the correct MSI version number for release and ESR

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement, P1)

Description

[Molly Howell (she/her) (no longer active)]

Currently our MSI repack is leaving the MSI version number field empty because we don't have a general way to map the version string from any channel onto the Microsoft format. But, release and ESR versions (which are three numbers separated by dots) do map trivially to Microsoft versions (which are four numbers separated by dots). If we fill in the correct version number for just ESR and release builds, but leave the other channels with 0.0.0.0, that would probably solve a huge majority of the overall issues.

Comment 1

[Werner Kessel]

It would be very helpful if the MSI version number field would be filled with a corresponding version number.
Currently it is not possible to deploy a new version via Intune to our Workstations. I have deployed Version 65.0 which is identified as 0.0.0.0 but when I now try to upload the Version 65.0.2 I get this error:

Update this app by selecting a newer line of business app package. The version of your existing package is [0.0.0.0], and the one you selected has version [0.0.0.0]

And the upload is blocked.
In addition to that, all Workstations get Version 65.0 installed over and over again. Also when the Mozilla updater have installed the latest Version 65.0.2. So we are having downgrades all the time, even if I set "Ignore App Version" that is defined as follows:

'Set this to yes for apps that are automatically updated by the app developer (such as Google Chrome)'

Comment 2

[Olav Birkeland]

(In reply to werner.kessel from comment #1)

It would be very helpful if the MSI version number field would be filled with a corresponding version number.
Currently it is not possible to deploy a new version via Intune to our Workstations. I have deployed Version 65.0 which is identified as 0.0.0.0 but when I now try to upload the Version 65.0.2 I get this error:

Update this app by selecting a newer line of business app package. The version of your existing package is [0.0.0.0], and the one you selected has version [0.0.0.0]

And the upload is blocked.
In addition to that, all Workstations get Version 65.0 installed over and over again. Also when the Mozilla updater have installed the latest Version 65.0.2. So we are having downgrades all the time, even if I set "Ignore App Version" that is defined as follows:

'Set this to yes for apps that are automatically updated by the app developer (such as Google Chrome)'

What, is it that bad? I too thought setting "Ignore version number" to Yes would fix the constant reinstalls.
Thanks for letting me know.

Temporary solution would be to repackage the exe installer (or MSI) as Intunewin with Win32 App Package Tool. Think I'll do just that for our couple of hundred clients who get Firefox through Intune. https://github.com/Microsoft/Intune-Win32-App-Packaging-Tool

Mozilla: It kind of defeats the purpose of having a MSI if it does not comply to MSI standards.

Comment 3

[Justin Wood (:Callek)]

(In reply to werner.kessel from comment #1)
(In reply to Olav Birkeland from comment #2)

Thanks for the comments, I'd like to take this opportunity to say that we have heard the issues with not having a version number present and this bug was filed explicitly to work on adding one in, for at least release and esr versions of Firefox. (Beta, Devedition, and Nightly are undecided at this time).

Comment 4

[Kim Moir [:kmoir] ET]

What is the priority of this request and what timeframe are you looking at getting it fixed?

Comment 5

[Molly Howell (she/her) (no longer active)]

I would love to have this in for 68 so that our initial launch of MSI on ESR doesn't have this problem. 69 (ESR 68.1) would probably also be good if that's not possible. Romain might have some other thoughts about this as well.

Comment 6

[Romain Testard [:RT]]

I agree, 68 would be ideal (ESR and RR since we'll have MSI installer for both at this point).

Comment 7

[Justin Wood (:Callek)]

:mhowell can you test https://queue.taskcluster.net/v1/task/ZU06bAZZTAOQzsrSb2tb_A/runs/0/artifacts/public/build/target.installer.msi (it is a try run, signed (dep cert) internals but msi unsigned) for win64.

This was built as if it was 68.0 release, so should have the version code.

If it looks right I'll put up a patch.

Comment 8

[Molly Howell (she/her) (no longer active)]

That looks correct to me, yes. Thanks a lot for getting to this so quickly, I wasn't expecting to see anything here so soon.

Comment 9

[Justin Wood (:Callek)]

Attachment: Bug 1535393 - Fill in the correct MSI version number for release and ESR.

Comment 10

[Justin Wood (:Callek)]

Comment on attachment 9053776 [details]
Bug 1535393 - Fill in the correct MSI version number for release and ESR.

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None
• User impact if declined: Users of the msi have more pain in automatically deploying it and updates
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This modifies the version code used on Release/ESR to be "actual" while still following similar paths as Nightly. Uplifting to beta will get us some user-facing testing (from 67 release) before the actual esr cycle ramps up.

This has also been testing on try "as if" it was a release.

• String changes made/needed:

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/984adcac77d3
Fill in the correct MSI version number for release and ESR. r=mhowell,nalexander

Comment 12

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/984adcac77d3

Comment 13

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9053776 [details]
Bug 1535393 - Fill in the correct MSI version number for release and ESR.

Good to have this fix a cycle before the next ESR, uplift approved for 67 beta 7. Thanks.

Comment 14

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1b9b7c6da0c3

Comment 15

[Mike Kaply [:mkaply]]

mhowell: Does this affect 66? Should we request release uplift if there is a . release?

Comment 16

[Molly Howell (she/her) (no longer active)]

66 is affected, yes. This patch is so low risk that I would support requesting uplift for it as a ride-along even though the impact for release 66 is probably pretty light.

Comment 17

[Mike Kaply [:mkaply]]

Comment on attachment 9053776 [details]
Bug 1535393 - Fill in the correct MSI version number for release and ESR.

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None
• User impact if declined: Users of the msi have more pain in automatically deploying it and updates.
  The reason I'm requesting for 66 is because it's low risk and we've had quite a few complaints.
  Will also make it easier for some upcoming deployments.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This modifies the version code used on Release/ESR to be "actual" while still following similar paths as Nightly.

This has also been testing on try "as if" it was a release.

• String changes made/needed:

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

So far, we don't have another 66 dot release planned.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9053776 [details]
Bug 1535393 - Fill in the correct MSI version number for release and ESR.

With only 3 weeks to go until 67 release, let's let this wait for 67.

Comment 20

[Olav Birkeland]

v67 seems to have fixed it for Intune, good job. Image

Still blank values with PowerShell (but thats just meta data/ tags right?). Image

Comment 21

[Molly Howell (she/her) (no longer active)]

Glad to hear this has fixed an issue for you.

The PowerShell VersionInfo property doesn't appear to work on any MSI file; I assume it's looking for the type of version info resource that only exists in an executable (or DLL) file.