We need to either manually update the mozilla User-Agent string for each release or make it happen automatically. Right now we still say M18. :-(

FWIW, this is the prerelease field. The patch should, I think, be: Index: all.js =================================================================== RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v retrieving revision 3.199 diff -u -d -r3.199 all.js --- all.js 2001/01/17 00:13:37 3.199 +++ all.js 2001/01/17 20:51:15 @@ -28,7 +28,7 @@ pref("keyword.URL", "http://keyword.netscape.com/keyword/"); pref("keyword.enabled", true); pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties"); -pref("general.useragent.misc", "m18"); +pref("general.useragent.misc", "0.8"); pref("general.startup.browser", true); pref("general.startup.mail", false);

I guess it should be m0.8 since the prerelease field is supposed to start with a letter. I guess the prerelease field doesn't really fit our current version scheme.

*** Bug 64698 has been marked as a duplicate of this bug. ***

If we don't want to update the version number manually in the user-agent string why don't we just call the release "trunk" like it does in the directories in /pub/mozilla/nightly/ the build id is listed after Gecko/ and it's not a release so really has no version number. Then for a release the value can be set as appropriate 0.7, 0.8, 0.9 rather than "trunk" Like so (slightly modified): Index: all.js =================================================================== RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v retrieving revision 3.199 diff -u -d -r3.199 all.js --- all.js 2001/01/17 00:13:37 3.199 +++ all.js 2001/01/17 20:51:15 @@ -28,7 +28,7 @@ pref("keyword.URL", "http://keyword.netscape.com/keyword/"); pref("keyword.enabled", true); pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties"); -pref("general.useragent.misc", "m18"); +pref("general.useragent.misc", "trunk"); pref("general.startup.browser", true); pref("general.startup.mail", false);

Naming the version "trunk" would really solve the need of manual version update. However, we may miss seeing the version number around the psychologically important "1.0". I will repeat my idea (the DUPLO bug) to name the version of nightly builds "0.7+" after milestone release 0.7, and so on. It needs a manual cjhange every 5 weeks (or so) but gives some additional important information. And is consistent with the ancient Mozilla tradition :-)

Something more consistent with the way we name the builds might be: * on the trunk, use "pre-0.8" (e.g., where we are now) * on the branch, change to "0.8" I guess I don't really like the idea of removing the version number for releases, as the user-agent spec says we should. (Does 0.8 qualify as a release rather than a prerelease?) That would require changing the user-agent spec (again)...

For reference, the current UA string spec is http://mozilla.org/build/revised-user-agent-strings.html

Actually after studying the UA string specs, I see we have no field for actual version: - the version.subversion is always 5.0 and seems cast in stone - it's not a version of Mozilla as we mean it, rather the generation of browsers - Gecko version is what we use for the build number and more actually (as the specs say)it is: "The Gecko product token allows products that embed the Gecko engine, including Mozilla, to identify this significant sub-product." This again is not the version of Mozilla (the one that aims at 1.0 as the final product). - PrereleaseVersion (the one we waste with m18 at present) as the name suggests is supposed to be used in pre-release versions only. But this is the only field where we may put the real Mozilla version (not 5.0 which is something else). I believe the US specs need changing. Definitely we need something more meaningfull than "trunk". We may drop the field as well as using "trunk" - no meaning would be lost. The last milestone has "0.7" (not "m0.7" as the PrereleaseVersion. This means the "String whose first character is [a-zA-Z]" rule has been already broken. I believe it may be dropped, unless there is a good reason for it. Like "0.7+" I proposed. If not, "pre-0.8" is also a good name for the trunk before the next milestone (not as clear for the eye but more Linux-like). Sorry for the long rant but I believe some discussion on this is needed. The UA string is the business card of the browser, after all.

Does the mega-patch bug 66480 fix this one as well? I ask because it fixed bug 63102 which seeme to cover a very similar topic.

This has nothing to do with the installer.

this is typically a build config issue since we usually update the user agent string for new releases, etc. I think we already have a bug filed on this, but I'm not certain. This is a personal must-fix for 0.8, preferably before the branch. cc'ing leaf and jj.

related bug Jon refers to is http://bugscape.netscape.com/show_bug.cgi?id=3508 (update version number for mozilla 0.7 and Netscape 6.01 in the Mac "get info" string) I just update the patch to reflect 0.8 and checked it in. That will take care of the MacOS "Get Info" window.

is this fixed with http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/modules/libpref/src/init&command=DIFF_FRAMESET&file=all.js&rev1=3.205&rev2=3.206&root=/cvsroot

Well, the 0.8 branch work is. Moving to 0.9. We really do need a better system for what to call things on the trunk, and we probably need to update the spec to allow for the version for non prerelease and to begin with a number...

Good idea, especially as Mozilla0.8 will have probably "0.8" anyway (like the 0.7 milestone was just "0.7"). I've put forward 0.8+ for nightly builds between 0.8 and 0.9. Any takers? It looks better than pre-0.9. Especially in the About window. Try for yourself changing it in all.js and then checking chrome://global/locale/about.html

Asa convinced me that 0.8.1+ is the way to go... it's what we've been using for a while. It still disagrees with the UA string spec, though... We also need to decide if we want to move to "Mozilla/5.1" sometime...

I posted my reasons for moving upto Mozilla/5.1 on n.p.m.seamonkey: news://news.mozilla.org:119/3AD7C032.5FFE5E38@ukuug.org Basically I suggested that the bit after the 5. should follow the Mozilla version number so Mozilla/5.1 would be 1.0, Mozilla/5.11 would be Mozilla 1.1, etc The main reason I believe we *need* to change the UA before 1.0 is because of the XUL syntax changes recently applied and any remote XUL written for Netscape 6.0 will break in 6.5 and Mozilla 1.0, Beonex, etc. Read the thread in .seamonkey for more. I think if we stick with user agents like Mozilla/5.1 and Mozilla/5.11 we avoid the chance of breaking dodgy scripts that don't like the idea of a zero padded 3 digit minor version like Mozilla/5.010

In the three-digit format 1.0 would be 5.1(00) anyway. The question is what to do about 0.9.1 etc. 5.091 works OK, as long as we never have more than nine milestone releases between bumping up the next digit. I have no fear that we'll hit 1.0 long before 0.9.10, but one of these days--maybe starting with 1.0--we'll have a long-lived stable branch where we can't make that guarantee. We could try a 5.09.1 format, but we did try something like that at one point (5.0m13, roughly the format Netscape has used for beta versions except 'm' instead of 'b') and sites started rejecting us. The rejection is because financial sites tend to reject "unknown" browsers until they reassure themselves that it's OK. They appear to do this on a straight strcmp of the user-agent version; Netscape communicator has this problem every time we bump the "Mozilla/4.7x" user agent. As a generational marker I could go for changing "5.0" to "5.1" or whatever, as long as we don't change it very often and keep the changing sub releases buried in the comment. Speaking of stable branches, we're going to have to do something with the Gecko pulldate. The last time we had a long branch (when Netscape shipped 6.0) it used Gecko/20001108, but that was a lie because the code had little to do with the Gecko of that date. 6.0 was really Gecko/20000922 plus a bunch of fixes. Branch developers aren't going to want to stick to the same version for the life of a long branch though, that's confusing to everyone. With the possibility of another Netscape shipping branch coming up, and the likelyhood of a mozilla 1.0 "stable branch" we need to figure this out. My preference would be to use a sub-version that's number of days since the branch; it's compact and relatively simple. The main drawback is that people think in dates more easily than number of days, but any format that preserves the real date is much bulkier. Netscape's 6.0 and 6.01 ship dates would have been Gecko/20000922.47 and Gecko/20000922.131, the typical mozilla milestone might look like Gecko/20010418.7 Zero-filled form would be better for mathematical comparisons between *branch* builds, but to handle the expected lenght of a potential stable branch we'd have to use a lot of digits. date-based forms get even uglier since we'd have to leave room for the year just in case we shipped a milestone near the end of December.

> I have no fear that we'll hit 1.0 long before 0.9.10 If the 1.0 definition document is anything to go by, I would not be so sure! ;-) > Netscape's 6.0 and 6.01 ship dates would have been Gecko/20000922.47 and > Gecko/20000922.131, the typical mozilla milestone might look like > Gecko/20010418.7 I like it. (A lot.)

I agree with dveditz's comments about the use of the Gecko/ part of the user agent, his comments about the Mozilla/5.1 jump also make sense and based on what he says I think we should go for Mozilla/5.1 for the 1.0 release but keep it like that for any milestone releases (1.1, etc) and then only change it again for the next major version (2.0) which would be Mozilla/5.2. The distinction between 1.1 and 1.2 can be left in the pre release field of the comment part. If we adopt this scheme we should also make 0.9 use the Mozilla/5.1 string if this is going to still be the recommended beta point for embedders and Netscape (this is because more people will see a beta release and people would like to know what user-agent string that Mozilla 1.0 and Netscape 6.5 will be using by release.

I think its too late in the milestone cycle to fiddle with fundemental user agent changes and try and deal with their possible side effects. moving this off the 0.9 radar.

regardless of the long term solution, as soon as we branch we need to update the branch and trunk both.

asa - this bug has been sidetracked into debate hell. I'd recommend filing a separate bug to just update the existing user agent as is on the trunk and branch and set that one to mozilla 0.9.

bug 77185 filed for Mozilla 0.9 user agent update. pushing this out to 0.9.1 TM (please forgive the trespass).

updating summary to better reflect bug. this doesn't need to get done for 0.9.1 or 0.9.2 so moving to 0.9.3.

Well, if that's what the bug's become (which isn't how it was originally intended), why did we add "rv:"?

David: Probably because the UA spec (linked to from this page) says about "PrereleaseVersion" field (presently rv:0.9+ for the trunk): "String whose first character is [a-zA-Z]. By convention, used to indicate pre-release versions, such as beta quality software, or milestones. This should not be present in final release software." This field is the issue we seem to target in this bug now. By adding "rv:" we obey the specs. OK. So what exactly do we need to do before mozilla0.9.3? Update the specs?

The original intent of that field was that it not be used for releases. We could argue about whether 0.9 or 0.9.1 is actually a release, but I think we've basically made the decision that it *should* be used for releases. Since not all our releases start with "b" (beta) or "m" (milestone) I was thinking we should drop that restriction from the UA spec and note officially that the field should be the release version rather than prerelease version only.

The reason for using "rv:"--an earlier published spec had "prv:"--was to provide a searchable token that was unlikely to otherwise occur. Without something like this reliably pulling the version out of the UA programatically is difficult.

Sorry for the spam, but is there a way to at least modify the user agent via editing a pref file? I am tired of microsoft not letting me enter some sites because i am not using internet explorer. That is discrimination I tried to search for bugs related to this but i did not find something like "change user agent", but i think i saw some time ago about a way to change it manually, because no UI was available. Other browsers like konqueror do this...

Should this bug be closed ?

dbaron?

Still need to do comment 28 and perhaps some other things.

Ok, well, here's one option.

The modified spec (attachment 85100 [details] [diff] [review]) still mentions UA's that have values other than Mozilla/5.0, has it been decided what is going to be done in the future - are we ever going to increment Mozilla/5.0 in the future?

Somewhere lost in the things drivers are supposed to be deciding is a format for changing the Gecko part of the token. I think I owe an update of the spec which I've been too busy to work on, although we did send in a text spec. I still favor something like my comment 18, but in compromise with the evangelism team we ended up with something more complicated. It's been posted to npm.seamonkey a couple of times.

In the almost six years since the last comment above, the User-Agent string has evolved. The current trunk setting for SeaMonkey on my machine, for instance, is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033001 SeaMonkey/2.0a1pre". The field this bug was about (between rv:<something> and the closing parenthesis) has disappeared, and a new "Product/Version" has appeared at far right, in this case "SeaMonkey/2.0a1pre". I believe that everything this bug was about has been taken care of one way or another. If someone thinks this still isn't FIXED, please speak up.

Because it seems obvious this bug is no longer valid I'll take the risk of marking it as WORKSFORME (not FIXED because I did not fix it). If anyone disagrees, please feel free to reopen.