1309372 - Wrong Lightning version in SeaMonkey 2.46 build 6 Release Candidate

Status: RESOLVED FIXED

(Calendar :: Build Config, defect)

Description

[Frank-Rainer Grahl (:frg)]

Attachment: Capture.PNG

Release candidate seems to work fine but shows a wrong .4.46 version for Lightning.

Downloaded from here:
https://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build6/unsigned/win32/en-US/

Comment 1

[Frank-Rainer Grahl (:frg)]

Possibly a duplicate or followup of bug 1293943.

Comment 2

[Frank-Rainer Grahl (:frg)]

Fallen,

wrt your comment yesterday on irc. Can the use of MOZ_PKG_VERSION be dropped from the makefile code which generates the Lightning version? I think the Thunderbird version is always accessible/usable or not?

FRG

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

It was probably added for a reason. I assume that reason is that for release or beta builds, MOZ_PKG_VERSION may be set to something different than in version.txt

Comment 4

[Frank-Rainer Grahl (:frg)]

Hmm, what do you suggest? 

Maybe testing for SeaMonkey, setting a different variable with the content of MOZ_PKG_VERSION when not SeaMonkey and use this for version generation?

Or changing makeversion.py to detect the SeaMonkey version?

Comment 5

[Philipp Kewisch [:Fallen][☁️📆]]

You could try an if/else block that uses what we are doing now for Thunderbird and ignoring MOZ_PKG_VERSION otherwise. In the worst case this may mean wrong version numbers in the Seamonkey builds in situations where building Thunderbird on the same tree would have a difference between MOZ_PKG_VERSION and version.txt.

If you are making changes to both lightning and gdata Makefiles, you might also want to refactor all the version variables into calendar/lightning/versions.mk and include from both.

Comment 6

[Frank-Rainer Grahl (:frg)]

Attachment: 1309372-lightning-version.patch

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: Seamonkey release builds include a lightning with wrong version information.
Testing completed (on m-c, etc.): c-r
Risk to taking this patch (and alternatives if risky): low
String changes made by this patch: none

Comment 7

[Philipp Kewisch [:Fallen][☁️📆]]

Can you do a Thunderbird try run for this?

Comment 8

[Frank-Rainer Grahl (:frg)]

I likely didn't use the right try syntax to build all platforms but the patch looks ok to me. The bustage in the x64 test is from a different bug.

Checking the logs I see -DLIGHTNING_VERSION=5.4a1 which is the expected result.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=6277ffac4e6503d78a84a5ba0924079b694973d7

Comment 9

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/807b9f10a95cba9260196561fb9c3fc719ef54c9

I will wait till tomorrow and push them to the branches then.

Comment 10

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/releases/comm-aurora/rev/855b5d14f40eeace2f785c8402c547d10157f44b
https://hg.mozilla.org/releases/comm-beta/rev/325cc1eb915498dff0b15a2cd594640827829212
c-r approval via irc
https://hg.mozilla.org/releases/comm-release/rev/98e75b3d030b0fb0ac52bc97a9db0b4e48175b1a