Closed Bug 302046 Opened 17 years ago Closed 15 years ago

File version numbering is broken (Windows version resource)


(Firefox Build System :: General, defect)

Windows XP
Not set


(Not tracked)



(Reporter: christian.stefan, Unassigned)


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:

Files are not versioned acording to versioning rules, eg (filever.exe output):

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

1.7.8  W32i DLL ENU shp js3250.dll 
1.7.10 W32i DLL ENU 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
2. Unzip
3. Compare file versions (either with filever.exe or using Explorer-

Actual Results:  
Newer (changed) files have same or lower version numbers

Expected Results:  
Newer (changed) files have higher version numbers
Version: unspecified → 1.7 Branch
Actually, the version that is incorrect is this: 2006011112

Versions shouldn't contains spaces or colons.

This is a major problem for even beginning to investigate doing "proper" windows installs.

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
Component: General → Installer
Ever confirmed: true
Product: Mozilla Application Suite → Firefox
Version: 1.7 Branch → Trunk
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:

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:

Windows Installer Version data type explained:

"The Version data type is a text string containing a valid version string. A version string has the format
where x is a digit.
The maximum acceptable version string is 65535.65535.65535.65535."

>1) tell MSI to ignore version resources

>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.
Assignee: general → nobody
QA Contact: general → installer
component -> build config.
Component: Installer → Build Config
QA Contact: installer → build.config
This situation has gotten worse. See my post at:

For Firefox, the File version is 1.8.20070.31202

and for Firefox, the File version is 1.8.20070.30919

So Firefox is greater than Firefox

At the minimum, this should have been, 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, see firefox.exe version data obtained using Explorer:

File version 1.8.20070.51502
(Other version information) File version 2007051502

File version 1.8.20070.5781
(Other version information) File version 2007071317


* last part of file version (5781) for is less then the same value for (51502)
* there are two different version readings for!
Benjamin removed file versioning completely on trunk.  I don't think we'll have a solution for branch, though.

and then our solution:

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 would then have fileversions of "", and we could make 3.0a7 be "".
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.
Closed: 15 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 386740
No longer blocks: MSI
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.