User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.10/mozilla-win32-1.7.10.zip Files are not versioned acording to versioning rules, eg (filever.exe output): 1) 1.7.8 W32i DLL - 1.7.20050.51112 shp accessiblemarshal.dll 1.7.10 W32i DLL - 1.7.20050.6071 shp accessiblemarshal.dll So accessiblemarshal.dll from 1.7.8 has a higher version number than 1.7.10 2) 1.7.8 W32i DLL ENU 4.0.0.0 shp js3250.dll 1.7.10 W32i DLL ENU 4.0.0.0 shp js3250.dll Although the file has changed the version number has not. This bug makes version numbering useless. Furthermore files won't be replaced if repackaged and installed with Windows Installer (MSI-)Packages. Windows Installer does strict file version number checking on versioned files. Reproducible: Always Steps to Reproduce: 1. Unzip mozilla-win32-1.7.8.zip 2. Unzip mozilla-win32-1.7.10.zip 3. Compare file versions (either with filever.exe or using Explorer- >Properties->Version) Actual Results: Newer (changed) files have same or lower version numbers Expected Results: Newer (changed) files have higher version numbers

Actually, the version that is incorrect is this: 1.8.0.1: 2006011112 Versions shouldn't contains spaces or colons. This is a major problem for even beginning to investigate doing "proper" windows installs. 1.8.0.1.2006011112 will not work I'm wondering if we should remove the build number from file versions completely. Also, should Firefox specific files be 1.5.X.X and Gecko files be 1.8.X.X

What is the root problem here? That MSI interprets some meaning out of the version resources and we use a different meaning? Can we 1) tell MSI to ignore version resources 2) move our meaning into a different (custom, even) version resource?

>What is the root problem here? That MSI interprets some meaning out of the >version resources and we use a different meaning? Can we Yes, that's the problem. VERSIONINFO explained: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/versioninfo_resource.asp Windows Installer uses FILEVERSION: "Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, "FILEVERSION 3,10,0,61" is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2)." There is a StringFileInfo block with a FileVersion string field. This version information (arbitrary string) is shown to the user but not used by Windows Installer. Windows Installer File Versioning Rules explained: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/released_versions_of_windows_installer.asp Windows Installer Version data type explained: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/version.asp "The Version data type is a text string containing a valid version string. A version string has the format xxxxx.xxxxx.xxxxx.xxxxx where x is a digit. The maximum acceptable version string is 65535.65535.65535.65535." >1) tell MSI to ignore version resources No >2) move our meaning into a different (custom, even) version resource? Yes, you can add a custom resource. Nevertheless you should fix file versioning, too.

-> default assignee/qa, though this strikes me as more a Core: Build Config bug.

component -> build config.

This situation has gotten worse. See my post at: http://www.kaply.com/weblog For Firefox 1.5.0.11, the File version is 1.8.20070.31202 and for Firefox 2.0.0.3, the File version is 1.8.20070.30919 So Firefox 1.5.0.11 is greater than Firefox 2.0.0.3 At the minimum, this should have been 1.8.1.20070.30919, but that wouldn't have fixed this problem because we were already broke with 1.8 which should have been 1.8.0 We really need to get the build numbers out of hear as was pointed out before. We can create a custom resource to store the build numbers, I believe and just use regular versioning...

We have problems deploying 2.0.0.5, see firefox.exe version data obtained using Explorer: Firefox 2.0.0.4 --------------- File version 1.8.20070.51502 (Other version information) File version 1.8.1.4: 2007051502 Firefox 2.0.0.5 --------------- File version 1.8.20070.5781 (Other version information) File version 1.8.1.5: 2007071317 Problems: * last part of file version (5781) for 2.0.0.5 is less then the same value for 2.0.0.4 (51502) * there are two different version readings for 2.0.0.5!

Benjamin removed file versioning completely on trunk. I don't think we'll have a solution for branch, though.

See: http://www.kaply.com/weblog/2007/04/12/firefox-internal-versioning/ and then our solution: http://www.kaply.com/weblog/2007/04/23/firefox-and-the-windows-registry/ We (IBM) gave up on using the internal Firefox file version and used the registry. And incidentally: > Benjamin removed file versioning completely on trunk. I don't think we'll > have a solution for branch, though. That's a really crappy solution. Why not just fix file versioning?

What's the right fix? I think the problem here is that nobody has specified what the expected result should be. Should we be using Gecko versioning, minus the build ID (which is what appears to have been screwing you up)? Should we be using App versioning (how does that work with XULRunner)? bsmedberg removed it while whacking the build ID code. That doesn't mean we can't put it back, but I think we should have a clear idea of what we want first.

Well, there are a couple things here. 1. Mozilla should stop taking up 4 slots for things that only require three. Why are security releases using slot 4 instead of slot 3? It should be 2.0.1, 2.0.2, 2.0.3. This would free up the fourth slot for something else like the build ID. 2. The Build ID doesn't necessarily need to be in the version. Just add a custom field to the EXE for the build ID. 3. Don't put a colon in the file version. 4. Don't put letters in the file version.

Ok, so: 1) is not something we can fix in the 2.0 branch, since we've crossed that bridge. I think I've seen discussion about making the 3.0 release be numbered 3.0.x, but that's out of scope here anyway. 2) I don't know that we need Build ID in the file version info at all 3 & 4) should be solvable. If we just took the Gecko version (numbers only) and used that as the fileversion, would that solve your problems? For example, Firefox 2.0.0.6 would then have fileversions of "1.8.1.6", and we could make 3.0a7 be "1.9.0.0". http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/config/milestone.txt&rev=3.27.2.14.2.2 http://lxr.mozilla.org/mozilla/source/config/milestone.txt

I do not want to munge alpha/beta/pre versions to remove the correct version lettering. If we can come up with a solution so that official releases have fileversion resources and betas don't, that's ok. Otherwise we should just ditch the fileversion resource altogether, because it can't accurately represent the actual version number of the software.

iirc MSI is going to need valid version numbers to perform updates so just doing it for official releases would prevent testing of MSI updates with nightly builds.