Jeremy M. Dolan wrote: > >>In fact, mozilla.org **itself** releases are branch based > > Yes, this is a good point, which I believe someone beat you to. This > points out a big problem. > > As soon as a release branches, the trunk is prone to change rapidly, > as high risk fixes waiting for the freeze to end all are checked in.
Exactly, this has always been my point. Thank you for getting it. Something has to tell you that the 0.9.6 release Gecko/20011120 (browser or just embedding engine) is not the same as the trunk Gecko/20011120 nightly of the same day. Currently the only thing that does that is the rv: value buried in the comment field of the Mozilla product token (which embed clients might not have according to the UA spec). I **ABSOLUTELY** agree that putting that information into the Gecko token itself would be better, that's why I threw out my Gecko/20011109.11 idea. It doesn't immediately jump out at you which milestone something is, but UA's are more for machines so it may not be all that important. Especially if the release info is moved into a mozilla.org vendor token as you propose. My proposal had the advantage of being easily comparable between builds, but I'm not totally in love with it if someone comes up with something better. >>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 a separate issue then the Gecko token. I feel Mozilla should > ship with a vendor token, rather then a rv: in the comment field. Ok, fine, IFF the branchness is contained in the shared Gecko token (which is, IMO, the right thing anyway). > That said, anything more is "fluff". Meaning, it has no > practical use, other then filling up millions of access.logs, and > being parsed by some poor Perl script, then gziped up, and eventually > wasting space on some backup tape. In that case, and if the Gecko token contains the branch info, then an extra mozilla.org/Seamonkey vendor token is "fluff". Let vendors who want to advertise themselves do the log bloating. >>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. > > Absolutely. But as you can see from your own words, rv: has nothing to > do with that. In fact, I want to switch FROM rv: based on the same > logic and motives in your above sentence. Being "Gecko/X Seamonkey/Y" > and "Gecko/X Netscape6/Z" makes Gecko/ the only LCD. I have no love for the rv: token, I'm holding on to it as leverage to get the Gecko token fixed. It appears to have worked in at least your case :-) > First we have the Mozilla/ token, which is now decreed to be 5.0 > indefinitely. It's for compatibility, and indicates nothing. It's a shame, but I bow to reality as strongly expressed by the evangelism team who would know. > Gecko/ Token Idea 1: [...] > During 0.9.8 freeze: Mozilla/5.0 (blah) Gecko/20020109 Seamonkey/0.9.7+ > 0.9.8, after branch: Mozilla/5.0 (blah) Gecko/0.9.8 Seamonkey/0.9.8 > Trunk after branch: Mozilla/5.0 (blah) Gecko/20020110 Seamonkey/0.9.8+ > NS6 branded 0.9.8: Mozilla/5.0 (blah) Gecko/0.9.8.1 Netscape6/6.5 I don't like Gecko alternating formats, very confusing, although I recognize you're trying to avoid branding a non-release build as that release. What about Gecko/0.9.7+ for the post-0.9.7 trunk (or Gecko/0.9.8dev or something)?. The daily timestamp turns out to be useful to lots of people in the Mozilla community (QA, bugzilla maintainers) so perhaps preserve it in an additional comment field. Gecko/0.9.7 (20011120) One of my proposals was similar to this (not sure if it was in mail or in this thread): Gecko/0.9.4.20011109, where the last .N was the current format and the stuff before was the rv: value. The objection I got was that this is so different from our current format that it'll break people (according to the evangelism team there *are* sites using the Gecko token to work around bugs or even block early versions for privacy problems). Another problem is that 1.0 would look like 1.0.2002xxxx which initially appears "later" than 1.0.1.2002xxxx if you don't parse it as two things--using the same delimiter is a bad idea. Better might be Gecko/0.9.7-20011120 or 0.9.7#20011120 (both '-' and '#' sort before '.' which is an advantage, I think). I still like the form or something like it, but those compatibility objections are why I proposed Gecko/20011109.11 (20011109+11 if you like, but I think we'll then have to answer a lot of questions from people who really don't care and who would otherwise be lulled by the familiarity of the '.'). My other proposal, "Gecko/20011120 (rv:0.9.6)", is perhaps my least favorite, but might better sail over the compatibility objections. The branch info has been moved to the Gecko token which is my main goal (although in a comment which makes it look less important), the date part is parsed as now, and people currently searching for "rv:" as in the spec will still find it. Release vs. trunk is indicated by the '+' as now. > Gecko/ Token Idea 2: > > During 0.9.8 freeze: Mozilla/5.0 (blah) Gecko/0.9.7+254 Seamonkey/0.9.7+ > 0.9.8, after branch: Mozilla/5.0 (blah) Gecko/0.9.8 Seamonkey/0.9.8 > Trunk after branch: Mozilla/5.0 (blah) Gecko/0.9.8+1 Seamonkey/0.9.8+ > NS6 branded 0.9.8: Mozilla/5.0 (blah) Gecko/0.9.8.1 Netscape6/6.5 Similar (yet more compact) than my favored proposal > The +254 in the 0.9.8 freeze indicates 254 gecko-changing checkins occurred > since "0.9.7". This also eliminates the issue of a CVS pull on > midnight and one 23 hours 59 minutes later having the exact same Gecko > version, regardless of how many major changes may have gone in that > day. number of checkins will be much harder to determine than something date oriented (and would even differ in the embedded vs. browser release, or whether it was an SVG or MathML build or not). When the Gecko day format was proposed it originally contained hour information as well, but at the time there was general agreement that day granularity was good enough. It's a little ambigous, but in the larger scheme of things it's more than good enough. Still, if we agree on an additive format like this and want more granularity we could always do hours instead of days. > OK. I'm *really* frickin' tired of typing. Please just agree so I > don't have to post again. :) I'm glad we agree that the Gecko token should contain the branch information, and if it does I'm more than happy to zap the rv: field from the Mozilla comment. I don't feel the need to rush into an agreement on the chosen format, we should pause and see if we have general agreement this far (especially from [EMAIL PROTECTED]). Once we're all there we can argue formats. > P.S.: The name of Mozilla's VendorOrOrganization token doesn't have to > be Seamonkey, as some seemed to have a, "distaste" was it, for the word. > Consider it a placeholder. Another [EMAIL PROTECTED] decision, ultimately. -Dan Veditz
