(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #324760 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=324760 Imported into Bugzilla on 03/03/99 11:44) The build number is currently generated at build time and munged into about.html. Since this file ends up in front end UI resources on Mac and Windows, any patch that would bump the build number needs to apply to localized files, creating the need for more patches (i.e, this makes patching language dependant). The build number belongs in the binary on all three platforms.

I think this would be trivial to implement on UNIX, but I don't know how it would affect the other platforms. about.html gets converted to a header file on UNIX and then included by xfe/icons.c, so changing the build number string in about.html to "...blahblah-%d" ought to work just fine. How the other platforms would deal with it, I don't know. Does the build number really matter, with respect to localization? I mean, if the base (english) build was rebuilt, the build number would (in theory) be updated, but if that was all that changed in the about page, who cares? Why even bother patching the previously localized about page? What am I missing here? What's a "front-end UI resource"?

I think this would be trivial to implement on UNIX, but I don't know how it would affect the other platforms. about.html gets converted to a header file on UNIX and then included by xfe/icons.c, so changing the build number string in about.html to "...blahblah-%d" ought to work just fine. How the other platforms would deal with it, I don't know. Does the build number really matter, with respect to localization? I mean, if the base (english) build was rebuilt, the build number would (in theory) be updated, but if that was all that changed in the about page, who cares? Why even bother patching the previously localized about page? What am I missing here? What's a "front-end UI resource"?

This is an example of something that probably *should* be a hard-coded string. I'd put the magic number into a global variable, statically initializing it whatever we're currently putting into about.html: == in buildno.h (generate this with your chron script) === #define BUILD_NUMBER 98089 == in buildno.c #include "buildno.h" int gBuildNumber = BUILD_NUMBER; In order to display the build number to the user: add another %s (or an %ld) into about.html, and display the number via the TITLE tag as you do now. This should be pretty easy to do, would allow tech support to track which US build a customer has, and would be valid for localized versions as well, with no localization whatsoever.

This has to do with patching and how we do localization: we want to separate all those things that are related to the program code itself, which includes version and build numbers, from UI stuff. Since we localize the already built product, we currently see the change in build number as a UI change. (When I say the about page "ends up in front end UI resources" I mean that to L10n, the about page is an RCDATA resource on Windows and a TEXT resource on Mac, not an HTML file or a Unix header. The build number is a static bit of text in those resource, not a variable.) If the build number were implemented the way Rob suggests, we could do a "code only" patch and not have to touch the UI, saving A LOT of effort across multiple localized products.

Does the build number really matter, with respect to localization? > I mean, if the base (english) build was rebuilt, the build number > would (in theory) be updated, but if that was all that changed in > the about page, who cares? Why even bother patching the previously > localized about page? What am I missing here? What's a "front-end > UI resource"? Two problems: 1) We can't really tell on international versions what version of netscape.exe (or its equivalent) the user *really* has. This makes it difficult to match functional bugs to the correct version. 2) It makes it more difficult to track when the UI has really changed. A binary file diff will say that resdll.dll has changed *every day*, even if the only thing that happened was that the chron script ran. While the script runs automatically, every time resdll.dll changes, at least two people (one in Mountain View, one in Dublin) have to investigate the change, to make sure we're not missing something important.

CC'ing mcafee for input on what this would require in the XFE.

slight duplicate of version number/identifier. i think we can do this in a xul file.

Put Ray Chen on list, since neither Rick or I are in Client.

Per donm, this bug is Fixed, Resolved, and Verified