Closed Bug 386740 Opened 18 years ago Closed 17 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: 17 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.

Attachment

General

Created:
Updated:
Size: