Jeremy M. Dolan wrote: > In article <[EMAIL PROTECTED]>, Stuart Ballard wrote: > >>How about Gecko/NS-62.20011019 - that is, Gecko/BranchName.Timestamp > > Nope. NSGecko would be fine though.
It's not Netscape's Gecko, Netscape ships exactly what is in the mozilla.org repository. Mozilla often ships releases where the "Gecko" portion is byte for byte copies of the corresponding Netscape release. For N6.2 mozilla.org only shipped source and a nightly, but for 6.0 and 6.1 there were matching full releases. The point of the "Gecko" part of the UA spec is to try to standardize on that token. Even for vendors who make non contributed changes to Gecko--unlike Netscape--the UA spec says to use the Gecko date of the version it's based on. We want sites to recognize above all the sameness of Gecko-based browsers (note: -based), not focus on the minor differences between them. >>For mozilla 1.0, the equivalent would be Gecko/Moz-10.20020108 (if we > > Nope. Mozilla uses "real" Gecko. As does Galleon, Kmeleon, Nautilus, > Konqueror, Skipstone, Beonex (sp), Warpzilla (AFAIK), [...]. So the Gecko > version for these 8+ should be the exact same. Most browsers are going > to just embed the rendering engine and not make any changes. Netscape > is the problem child :). In fact, mozilla.org **itself** releases are branch based, and thus all those other builds you mention. When 0.9.x is released it does *not* match the trunk Gecko for that day. By the time 0.9.6 was released on 11/20 there had been significant changes checked in since the branch was cut 11 days earlier. This is the usual pattern because "risky" changes are often held over to the beginning of the next milestone period. http://bonsai.mozilla.org//cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F09%2F2001+00%3A00%3A00&maxdate=11%2F20%2F2001+00%3A00%3A00&cvsroot=%2Fcvsroot That's 108 people checking in (+28955/22706) lines of difference between the "REAL" (trunk) Gecko/20011120 and the 0.9.6 release which claimed to be the same thing but was really based on Gecko/20011109. Of course the branch had it's own fixes which were also checked into the trunk, but subtracting them (+524/421) doesn't change my point. http://bonsai.mozilla.org//cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_0_9_6_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=11%2F09%2F2001+00%3A00%3A00&maxdate=11%2F20%2F2001+00%3A00%3A00&cvsroot=%2Fcvsroot> > But we're getting fairly off topic. My main issue with the current > U-As is Mozilla's own string doesn't match how others are supposed to > look, because of the rv: in the comment field, rather then a vendor > token. We're still on topic, which is how sites recognize and distinguish mozilla-based browsers. Mozilla releases don't have a vendor field because the vendor field indicated variants of the Mozilla indicated by the first parts of the UA. > This is made worse by Netscape shipping with Mozilla's rv: in > THEIR comment field. This is the fundamental disagreement we're having. Netscape's release *is* the Mozilla indicated by the rv: field (OK, 6.2 mistakenly said rv:0.9.4 instead of 0.9.4.1). The packaging is different (Netscape adds AIM, a spelling checker, a few plugins, and branding), but if you did a binary compare of the Netscape release and the equivalent Mozilla nightly the "Gecko" portion would be identical. This is because Netscape *copies* the Mozilla binaries and then merely adds additional binary stuff. We don't even recompile the shared code, let alone make changes to it. To a webserver the following clients would behave identically: Mozilla/5.0 ([...]; en-US; rv:0.9.7+) Gecko/20020108 Netscape6/6.2.1+ Mozilla/5.0 ([...]; en-US; rv:0.9.7+) Gecko/20020108 The vendor token can be ignored except for those who really care about the marketshare of various mozilla vendors. We don't *want* people to say Netscape6 has x% marketshare, Galeon y%, and mozilla.org z%, we want people to say Gecko or Mozilla has x+y+z%, of which x% is Netscape. mozilla.org has had a firm stance for nearly four years that they don't ship end-user builds, they only ship test builds. Since they aren't a vendor they don't need a vendor token. If we do change the source to stick something in the vendor field for mozilla.org no doubt any number of clueless people will end up shipping tweaked builds masquerading as a mozilla.org release because they can't follow the distribution instructions to change it. Would the following mozilla.org UA make you any happier? Mozilla/5.0 ([...]; en-US; rv:0.9.7+) Gecko/20020108 Generic The reason the form of the Gecko version is not tangential to your topic is that *something* needs to indicate "branchness". Currently it's the rv: field you want to do away with. I'd be happy to lose the rv: comment field if the Gecko token were changed in some way to make these distinctions. But not until then: without the rv: field Mozilla/5.0 ([...]; rv:0.9.6) Gecko/20011120 and Mozilla/5.0 ([...]; rv:0.9.6+) Gecko/20011120 would be indistinguishable when, as I've shown above, there are significant differences between the two. And note that neither of these is a Netscape release, these are both "REAL" Gecko. The branch build, in fact, has a better claim at being the "REAL" Gecko since it's the one that ends up archived in the "release" directory; the nighly trunk builds evaporate after a while. -Dan Veditz
