Closed
Bug 386740
Opened 17 years ago
Closed 16 years ago
Windows file versions are incorrect
Categories
(Core :: General, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: RyanVM, Assigned: benjamin)
References
Details
Attachments
(1 file)
12.65 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 4•17 years ago
|
||
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?
Comment 5•17 years ago
|
||
Yeah, that's not terrible. It will at least give us consistent and increasing version numbers, which is all anyone really wants.
Comment 6•17 years ago
|
||
+'ing and marking as P3.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Assignee | ||
Comment 7•16 years ago
|
||
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 8•16 years ago
|
||
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+
Assignee | ||
Comment 9•16 years ago
|
||
It will not break universal builds, see the hunk in config/Makefile.in which reads MOZ_BUILD_DATE
Comment 10•16 years ago
|
||
Oh, duh. Must have paged that first hunk out of my brain by the time I got to the bottom.
Assignee | ||
Comment 11•16 years ago
|
||
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•