Closed Bug 386740 Opened 17 years ago Closed 16 years ago

Windows file versions are incorrect

Categories

(Core :: General, defect, P3)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: RyanVM, Assigned: benjamin)

References

Details

Attachments

(1 file)

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


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?
Assignee: nobody → benjamin
Flags: blocking1.9?
Yeah, that's not terrible.  It will at least give us consistent and increasing version numbers, which is all anyone really wants.
+'ing and marking as P3.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Blocks: 411449
This appears to do what we want. It will regenerate the buildid every time you do a toplevel build (more specifically "export" in config).
Attachment #296719 - Flags: review?(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.
Attachment #296719 - Flags: review?(ted.mielczarek) → review+
It will not break universal builds, see the hunk in config/Makefile.in which reads MOZ_BUILD_DATE
Oh, duh.  Must have paged that first hunk out of my brain by the time I got to the bottom.
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Depends on: 412362
Depends on: 478161
You need to log in before you can comment on or make changes to this bug.