302046 - File version numbering is broken (Windows version resource)

Status: RESOLVED DUPLICATE of bug 386740

(Firefox Build System :: General, defect)

Description

[christian.stefan]

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

Comment 1

[Mike Kaply [:mkaply]]

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

Comment 2

[Benjamin Smedberg]

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?

Comment 3

[christian.stefan]

>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. 

Comment 4

[Phil Ringnalda (:philor)]

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

Comment 5

[Robert Strong (they/them - no direct email)]

component -> build config.

Comment 6

[Mike Kaply [:mkaply]]

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...

Comment 7

[Vitezslav Kotrla]

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!

Comment 8

[(not currently active) Ted Mielczarek]

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

Comment 9

[Mike Kaply [:mkaply]]

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?

Comment 10

[(not currently active) Ted Mielczarek]

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.

Comment 11

[Mike Kaply [:mkaply]]

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.

Comment 12

[(not currently active) Ted Mielczarek]

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

Comment 13

[Benjamin Smedberg]

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.

Comment 14

[Robert Strong (they/them - no direct email)]

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.