Include Lightning BuildID in install.rdf for easier QA work

RESOLVED FIXED in 1.0b1

Status

enhancement
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: ssitter, Assigned: ssitter)

Tracking

Trunk
1.0b1

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
After removing the BuildID from the Lightning description it is impossible to determine the exact BuildID. But the BuildID is required for some QA work, e.g. finding the correct regression range for a bug.

My suggestion would be to include the BuildID in a comment in the install.rdf file. This way testers can determine the BuildID by just opening the install.rdf file in a text editor.
(Assignee)

Comment 1

10 years ago
Reverts the Makefile.in changes from Bug 355927, displays the BuildID like
    <em:version>1.0pre</em:version> <!-- BuildID=20090224155515 -->
in install.rdf.
Assignee: nobody → ssitter
Status: NEW → ASSIGNED
Attachment #364379 - Flags: review?(philipp)
Can we maybe add the build id in a UI visible field for nightly builds only? Possibly dependant on MOZ_OFFICIAL and hijack <em:contributor> ?
(Assignee)

Comment 3

10 years ago
I think MOZILLA_OFFICIAL is always enabled, independent of building a hourly, a nightly or a release build. Maybe someone could add a better solution later but I'd go with the simple solution proposed above.
Maybe we could parse the version and all version strings ending on "pre" will add an em:contributor/em:developer?
(Assignee)

Comment 5

10 years ago
Posted image about dialog proposal β€”
The BuildID should be included for the release builds too. For example if the build server is switched to 'release mode' for several days, or there exists several rc-builds that all have the same final version number. This can be achieved by the simple patch above.

If the BuildID should be displayed in UI it could be done via the about dialog as proposed by Daniel, see attached screenshot.
Attachment #364379 - Flags: review?(philipp) → review+
Comment on attachment 364379 [details] [diff] [review]
[checked in] add BuildID to install.rdf

r=philipp
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b655b829638f>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
(Assignee)

Comment 8

10 years ago
How about the proposal from Daniel that is displayed in the screenshot from comment #5? Do we want to display it at all to the user?
I guess searching for pre would work. I think we should display this information in nightlys, especially for testdays etc.
Posted patch In all builds (obsolete) β€” β€” Splinter Review
Ah I should read more comments before posting my own. Two patches that do different things, r+ whichever you prefer. I'm indifferent. Remember that release builds are fully localized though,  and the em:developer tag can't be easily localized with the build id, unless maybe we provide the build id also in a .dtd file.
Attachment #365399 - Flags: review?(ssitter)
I think having it in "pre" and "rc" builds is sufficient (no need for l10n work).
(Assignee)

Updated

10 years ago
Attachment #365398 - Flags: review+
(Assignee)

Comment 13

10 years ago
Comment on attachment 365398 [details] [diff] [review]
Only in nightly builds

I see no sense checking for "rc" in the version number. If it is really a release candidate the version number is identical to the final release, e.g. "1.0". For all non-pre builds the BuildID is still available from the comment in the install.rdf file.

r=ssitter if you change PRE_VERSION to the more verbose LIGHTNING_PRERELEASE_VERSION because the PRE_VERSION define is already used in mozilla code.
(Assignee)

Updated

10 years ago
Attachment #365399 - Flags: review?(ssitter)
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
(Assignee)

Updated

10 years ago
Attachment #364379 - Attachment description: add BuildID to install.rdf → [checked in] add BuildID to install.rdf
(Assignee)

Updated

10 years ago
Attachment #365399 - Attachment is obsolete: true
LIGHTNING_PRERELEASE_VERSION it is.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4bc7910954ab>

-> FIXED
Keywords: checkin-needed
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.