Closed Bug 1535393 Opened 7 months ago Closed 7 months ago

Fill in the correct MSI version number for release and ESR

Categories

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

enhancement

Tracking

(firefox-esr60 unaffected, firefox66 wontfix, firefox67 fixed, firefox68 fixed)

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- fixed
firefox68 --- fixed

People

(Reporter: mhowell, Assigned: Callek)

References

Details

Attachments

(1 file)

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.

(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).

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

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)
Priority: -- → P1

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

: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.

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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:
Attachment #9053776 - Flags: approval-mozilla-beta?
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/984adcac77d3
Fill in the correct MSI version number for release and ESR. r=mhowell,nalexander
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee: nobody → bugspam.Callek

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.

Attachment #9053776 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

Flags: needinfo?(mhowell)

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.

Flags: needinfo?(mhowell)

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:
Attachment #9053776 - Flags: approval-mozilla-release?

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

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.

Attachment #9053776 - Flags: approval-mozilla-release? → approval-mozilla-release-

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

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

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.

You need to log in before you can comment on or make changes to this bug.