put build ID in separate file

RESOLVED DUPLICATE of bug 179052

Status

Core Graveyard
Tracking
P3
enhancement
RESOLVED DUPLICATE of bug 179052
19 years ago
2 years ago

People

(Reporter: Henrik Lynggaard Hansen, Assigned: bobj)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Hi

For the next generation of MozillaTranslator I would like the program to
automatically check to se if there has been installed a new mozilla version on
the translators machine.

To do this I need the build ID (and later possible other information) in a
chrome or product information file. I know the build ID is allready inserted
into navigator.dtd, but it is a bit slow to parse that just to read a single
value, plus there is the chance/risk that the build ID is removed from the label

My suggestion is to tweak the build process to produce a chrome information file
in the /bin/chrome dir e.g. called chrome.properties (java properties format)
with the single property

build.id=<build ID>

if the assigment is wrong feels free to change it. However I would like to have
a commitment and the "spec" by tuesday 1/2, so that I at lets know which file
and format in will be. this way I can start doing the tool, and manually make
the file for testning purposes until this "bug" is fixed

cheers from denmark
henrik

Comment 1

19 years ago
Hi, Henrik:


Build ID is used to keep track of the timestamp of a particular build. It might
not be a good idea to localize it. Instead, you may check the timestamp of some
important files such as mozilla.exe or components.reg. 
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

19 years ago
I guess you misunderstood me because my intention was NOT to localize it, but to 
use it for checking if the chrome has been updated.

The reason for not just using the file-date, is that the build ID contains more 
information than the file-date
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 3

19 years ago
I see... you're right. I think what we need is a perl script to parse this id 
out and dump it to a file. 

I suspect since you have the DTD parser module already, it might be easier if
you just build a parser out of it. 

I am working on some localizability issues for M14. Might not have cycle on this
issue. Sorry!



Comment 4

19 years ago
Set TFV to M18.
Target Milestone: M18

Comment 5

18 years ago
fix typo in summary
Summary: put build ID in separate infromation file → put build ID in separate information file

Comment 6

18 years ago
leger is no longer @netscape. changing qa contact to component's default
QA Contact: leger → chofmann

Updated

18 years ago
Target Milestone: M18 → ---

Updated

17 years ago
Summary: put build ID in separate information file → put build ID in separate file

Comment 7

15 years ago
Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!
Assignee: tao → bobj
Status: REOPENED → NEW
I think we do this now.  There's at least application.ini; there might be something else as well.  I remember getting talos performance tests reporting correctly depended on having build ship the build ID in them.

Comment 9

9 years ago
As far as I know there is now a ton of tools to tell localizers about required changes. Also, as David said, there is now application.ini which has version and buildID as clear text. I'm going to dupe this to bug 179052 as suggested there.
Status: NEW → RESOLVED
Last Resolved: 19 years ago9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 179052
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.