User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0 StumbleUpon/1.9991 Build Identifier: All Including Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0 Knowing what exactly which version of Fx is installed on thier PCs is very important to corporate customers (for security purposes in particular). Most software inventory scanners read the the properties of .exe files to indentify the Product, Vendor and Version infomation. This is what our sw inventory scanner gets from the firefox.exe (v1.01.): Product Name: Firefox Product Version: 1.7.6: 2005022518 Vendor: Mozilla This is a little confusing when you are trying to determine the "real" version of Fx that is installed on PCs on your network. I know that Product Version of 1.7.6 relates to the version of the gecko engine however, firefox.exe is not the gecko engine and it should report the Product Version of firefox not of gecko. Perhaps the gecko engine version (bundled inside firefox.exe) could be reported in a different (custom?) attribute in the .exe I think fixing this bug would be very easy to acomplish and I hope we can get it right for the final compile of Fx 1.0.2 to make corporate adoptors of Fx more confortable with rolling out Fx. See http://forums.mozillazine.org/viewtopic.php?t=228219 for more discussion on this issue. Reproducible: Always Steps to Reproduce: 1. right click the firefox.exe (in Windows) 2. select properties 3. click the Version tab 4. select the Product Version attribute. OR Run a sofware inventory scaner against a PC with firefox.exe on it and look at the results Actual Results: Version reported is NOT the Fx version but the Gecko engine version Expected Results: Compile firefox.exe with the version of Fx that it is i.e. 1.0.2 NOT the version of the Gecko engine
The official nightlies have the correct build number. Therefore, I'm willing to bet it's related to bug 277876. Try the solution in that bug and see if it works for you.
Same problem. Product Version value is 1.8b2: 2005031806 on the nightly. Same issue with the Fx 1.0.2 RC @ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-03-17-18-aviary1.0.1/firefox-1.0.2.en-US.win32.installer.exe
This has nothing to do with bug 277876. As for this bug, I'm indifferent, either way to me sounds fine. For what its worth, the File Version shows the Firefox version number. But keeping the Gecko version number somewhere in the file attributes sounds like a good idea too.
Yes, file version is correct but that really doesn't matter since the most popular commercial software inventory programs use the Product Version not the File Version. I agree that the exe should contain the Gecko version somewhere but not in the Product Version field.
Note Morpub: Tiny flub but you seem to spell infoRmation - INFOmation. You can't fix that in bug description but you can edit the title. Thanks! Also, I've took a random software's exe properties into account here and found the following (This may help the decision where to plant Gecko version number as well as "other" versions): •Comments •Special Build Description •Product Version •Private Build Description Now surely one of these can be singled out for a particular entry. Huh? Or, why the hell can't we add our own entry name (or, "namespace") such as Gecko (engine) Version? Unless there's some unwritten rule of thumb that started when MS was created - Like using only those specific comment entries?
Summary: Firefox.exe is compiled with incorrect Product Version infomation → Firefox.exe is compiled with incorrect Product Version information
MorPob, screenshots are unnecessary for stuff that is plainly apparent to even those who can't see the bug.
Can someone that uses MicroSoft's SMS or any other software inventory program on thier network confirm that it also uses .exe Product Version attributes to report version information? I think it is very important that version information is reported correctly to software inventory tools for corporate adoption of Fx.
Notwithstanding any feelings about MS, IE product information seems to convey all the data which FF tries to convey, in a manner which seems to me to be both full and useful (Properties panel/Version): File version: 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) Product version: 6.00.2900.2180 FF 1.0.3 currently displays in the same panel: File version: 1.0.3 Product version: 1.7.7: 2005040301 If Firefox displayed File version: 1.7.7: 2005040301 Product version: 1.0.3 Then the needed information would be in the expected places. This does not seem to me to be of extreme coplexity to implement.
Is there any possibily that we can get this into Fx 1.1?
Chase, what would it take to get the app version (i.e. 1.0.3) instead of the Gecko version here? This is important to corporate deployment types.
This is something we need for corporate stuff, and I know that versiontracker is broken by this as well.
Flags: blocking-aviary1.1? → blocking1.8b4+
cc'ing devs. This change is going to be made soon.
Status: NEW → ASSIGNED
see: http://lxr.mozilla.org/seamonkey/source/config/version_win.pl#218 http://lxr.mozilla.org/seamonkey/source/config/version_win.pl#400 changing OS to windows, this does not affect other OSes
OS: All → Windows 95
Created attachment 190279 [details] [diff] [review] Override product version with app version number While I'm here, bumping Firefox trunk version from 1.0 to 1.0+.
Attachment #190279 - Flags: superreview?(bryner) → superreview+
hmm, should maybe both fileversion and productversion be set?
I'm glad to see this bug being aggresively worked on but I am wondering... What attribute (of the exe) will the gecko engine version (i.e. 1.7.10: 2005071605) info be put after it is removed from Product Version?
(In reply to comment #17) > I'm glad to see this bug being aggresively worked on but I am wondering... > What attribute (of the exe) will the gecko engine version (i.e. 1.7.10: > 2005071605) info be put after it is removed from Product Version? File Version
(In reply to comment #16) > hmm, should maybe both fileversion and productversion be set? They are both set in version_win.pl. The patch changes which gets the override.
I don't want to be difficult here I would just like us to nail this bug once. From the poking around I've done in .exe attributes I'm a little confused. It looks like there is a long and a short File Version attribute in win32 exes. Examples notepad short 5.1.2600.2180 long 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) iexplore.exe short 6.00.2900.2180 long 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) write.exe short 5.1.2600.0 long 5.1.2600.0 (xpclient.010817-1148) From those examples it looks like the short version is actually the File Version up to the first space. However I looked at some other(non-MS) exes and they seem to not conform to that rule (because of a different format in the File Version?) Examples winword.exe short 11.0.6502.0 long 11.0.6502 winvnc.exe short 184.108.40.206 long 1, 2, 9, 0 This leads me to believe that either: 1)There two seperate version attributes (short and long) or 2)The rule(s) for generating the short version are more complicated that what I originally thought. Would it be wise to put a custom attribute to the exe like Gecko Build? Thanks for all your hard work guys, I wish I could help more to solve the issues and not just give you all more work to do.
I'm thinking now that there is a Short and a Long Verison attribute acrobat.exe short 220.127.116.118 long 18.104.22.1683051900
Comment on attachment 190279 [details] [diff] [review] Override product version with app version number Landed on the trunk. Checking in config/version_win.pl; /cvsroot/mozilla/config/version_win.pl,v <-- version_win.pl new revision: 3.11; previous revision: 3.10 done Checking in browser/app/module.ver; /cvsroot/mozilla/browser/app/module.ver,v <-- module.ver new revision: 1.11; previous revision: 1.10 done Checking in mail/app/module.ver; /cvsroot/mozilla/mail/app/module.ver,v <-- module.ver new revision: 1.7; previous revision: 1.6 done
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
I'm glad to see that this bug got resolved, thank you. Software inventory scanners now report Firefox version 1.0+. However, I wonder in general about the entire versioning scheme for Fx. 1.0+ does not really disclose very much information about the firefox.exe build. With this versioning system there would be no distinguishment between any nightlies and build canidates. Would the entire versioning scheme not be more usefull if it were something like 1.06.20050728xx to reflect the build number? I can't think of a reason why not to use this scheme. It would also make it easier for the 1.5 builds (extensions and themes in particular) with all DP nightlies, candidates and release being 1.50.yyyymmddbb.
(In reply to comment #23) > I'm glad to see that this bug got resolved, thank you. Software inventory > scanners now report Firefox version 1.0+. > However, I wonder in general about the entire versioning scheme for Fx. 1.0+ > does not really disclose very much information about the firefox.exe build. > With this versioning system there would be no distinguishment between any > nightlies and build canidates. > Would the entire versioning scheme not be more usefull if it were something like > 1.06.20050728xx to reflect the build number? > I can't think of a reason why not to use this scheme. It would also make it > easier for the 1.5 builds (extensions and themes in particular) with all DP > nightlies, candidates and release being 1.50.yyyymmddbb. I don't mean to offend you, but this isn't Mozillazine. The reply is off-topic for this bug. If you don't like it, file a new one (though I'm pretty sure they're taking steps to avoid using "+" stuff in the future) or post in on Mozillazine. But don't spam bugs with off-topic content please, for the sake of those of us who are on the CC list and don't want to wade through spam.
You need to log in before you can comment on or make changes to this bug.