386740 - Windows file versions are incorrect

Status: RESOLVED FIXED

(Core :: General, defect, P3)

Description

[Ryan VanderMeulen [:RyanVM]]

Currently, binaries are getting a file version of 1.9a7 which causes them to show 0.0.0.0 in the status bar. This regressed with the landing of bug 383167.

Comment 3

[skierpage]

(In reply to comment #0)
> Currently, binaries are getting a file version of 1.9a7 which causes them to
> show 0.0.0.0 in the status bar.

True for DLLs like xpcom.dll, but FYI xul.dll is different: it has no version at all and no version tab in File Properties.

Comment 4

[Benjamin Smedberg]

Yuck, I guess we need to deal with this for FF3... I thought I could remove the VERSIONINFO block entirely, but I can't because that's how we get publisher/description information, which we need for UAC dialogs.

So I'm proposing to following a VERSIONINFO scheme like this:

major.minor.release.dayssincejan12000

And set the VS_FF_PRERELEASE flag for any version that has a letter in it. Ted, does that sound like a reasonable plan?

Comment 5

[(not currently active) Ted Mielczarek]

Yeah, that's not terrible.  It will at least give us consistent and increasing version numbers, which is all anyone really wants.

Comment 6

[Damon Sicore (:damons)]

+'ing and marking as P3.

Comment 7

[Benjamin Smedberg]

Attachment: Embed major.minor.release.dayssincejan12000 in FILEVERSION, rev. 1

This appears to do what we want. It will regenerate the buildid every time you do a toplevel build (more specifically "export" in config).

Comment 8

[(not currently active) Ted Mielczarek]

Comment on attachment 296719 [details] [diff] [review]
Embed major.minor.release.dayssincejan12000 in FILEVERSION, rev. 1

>Index: config/version_win.pl
>===================================================================
> # PBI - your private build information (if not a milestone or nightly)
>@@ -85,64 +99,63 @@ sub getNextEntry
> 				$value =~ s/^\s*(.*?)\s*$/$1/;
> 				return ($entry,$value);
> 			}
> 		}
> 	}
> 	return undef;
> }
> 
>-my ($quiet,$privateinfo,$objdir,$debug,$official,$milestone,$module,$binary,$depth,$rcinclude,$bits,$srcdir);
>+my ($quiet,$objdir,$debug,$official,$milestone,$buildid,$module,$binary,$depth,$rcinclude,$bits,$srcdir);
> 
> GetOptions( "QUIET" => \$quiet,
>-		"PBI=s" => \$privateinfo,

Kill the comment (and any other mentions of this PBI param if you're going to kill the param.

>Index: toolkit/xre/make-platformini.py
>===================================================================
>-buildid = os.environ.get('MOZ_BUILD_DATE', datetime.now().strftime('%Y%m%d%H'))
> 
> if options.print_buildid:
>-    print buildid
>+    print datetime.now().strftime('%Y%m%d%H')
>     sys.exit(0)

Isn't this going to break Universal builds?  That's what MOZ_BUILD_DATE was for, right?

r=me with those fixed.

Comment 9

[Benjamin Smedberg]

It will not break universal builds, see the hunk in config/Makefile.in which reads MOZ_BUILD_DATE

Comment 10

[(not currently active) Ted Mielczarek]

Oh, duh.  Must have paged that first hunk out of my brain by the time I got to the bottom.

Comment 11

[Benjamin Smedberg]

Fixed on trunk.