In netscape.public.mozilla.seamonkey, you wrote:
> 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
Well, they create a new branch, a x.x.1, which makes Netscape special
among Gecko vendors as they have access to do so. Fair enough though, my
new idea covers this. Yes, conceivably the x.x.1 branch is open and
other vendors can use, just read on :).
> In fact, mozilla.org **itself** releases are branch based, and thus all
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.
This means a week later, by the time the release happens, the YYYYMMDD
trunk vs release Gecko versions are potentially very different.
My new idea covers this, read on :).
> 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. The
reason? Try to follow me carefully here. All a web site needs from the
User-Agent, in constructing a browser specific page, is the Gecko/
token, assuming it's unambiguous, which it will be when I'm done with
it. :) We also need to continue to pass the Mozilla/ token, for
compatibility. 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.
With me so far? Little more quoting, then the point is continued below.
> 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
It is true that this is currently the case. Two things. First: so
what? Who cares? What does it matter Netscape 6.xy happens to be based
off of Mozilla j.w.z? Does the website need to know probably the
skins are the same? And probably its Mailnews has the same features?
And /probably/ the image context menu is the same length? None of
these things are guaranteed in a different vendors release. Should
Galeon include the Mozilla rv:? How bout if it started using XUL for
its chrome? What if FooVendor starts with Mozilla 8.9, and starts
making significant changes? At what exact point should they no longer
be using Mozilla's rv:?
Second: This is the case now, that Netscape version X is very similar
(to the point that many parts are identical) to Mozilla version Y, but
this 1:1 relationship is by no means guaranteed. What happens then?
When Mozilla.org no longer has an interest in the 1.x branch, but
Netscape continues making bug fixes and enhancements to their 6.x
branch for customers? What rv: are they then, when Mozilla.org doesn't
want to bother with adding those changes back into 1.x as 2.0 is
already out. Do you drop rv: then, and have a different U-A syntax on
those releases? Does Netscape just make up it's own rv:?
> 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. Log parsers can
easily be written to record Gecko/X foo/Y as browser type gecko,
subtype foo, without needing to know foo existed beforehand. No
having to deal with foo not being there, so assuming it's
Mozilla.org's browser, and going back to the comment field to use
what's after some weird comment called 'rv:'.
> Since they aren't a vendor they don't need a vendor token.
Fine. Semantics. Let's rename VendorToken to
VendorOrOrganizationOrSomeRandomGuyDistributingThisVersion.
> 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.
There's absolutely no different between using Mozilla using
VendorToken or not, with regards to people not changing it. If they
don't change the current string we send, "M/x (...; rv:Y) Gecko/Z",
then they're "masquerading as a mozilla.org release" just as much as
they would be if they didn't change VendorToken.
Although, I doubt "any number of clueless people" is more then 0. The
first thing a person is likely to change is the U-A, as it's easy, and
neat (hey look! my dogs name is being sent to every site I go to!).
For any vendor release with more then 5 users, if they're not
following the U-A spec, I'm sure a polite e-mail to them would be all
it would take to have them send a proper one. I don't see this as a
problem.
> Would the following mozilla.org UA make you any happier?
> Mozilla/5.0 ([...]; en-US; rv:0.9.7+) Gecko/20020108 Generic
No. A generic what? A generic gecko based browser? Why isn't Galeon a
generic gecko based browser? Gecko and Mozilla may come from the same
organization, but they are different products. mozilla-the-browser has
no reason to be "special" to gecko. It may be the official example
implementation, but so what?
> 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:
>
> Mozilla/5.0 ([...]; rv:0.9.6) Gecko/20011120 and
> Mozilla/5.0 ([...]; rv:0.9.6+) Gecko/20011120
>
> would be indistinguishable
Right you are. Remember those two "read on"s about an hour ago? (Well,
an hour of typing, probably 10 minutes of reading.) Here's the master
plan. Revel in awe.
First we have the Mozilla/ token, which is now decreed to be 5.0
indefinitely. It's for compatibility, and indicates nothing.
Next is the comments. As they're commenting a now-meaningless token,
it's fairly up for grabs what should go in here, but for
compatibilities sake, the current OS/encryption/OS/locale mine as well
stay (unless we'd like to take some strides in privacy here). Only
change is rv: is removed.
Next up, Gecko, which currently uses a time stamp to double as its
version. I have two ideas here, and I really don't care which is
picked up, as they both eliminate rv:.
Gecko/ Token Idea 1:
The mozilla.org trunk continues to use a time stamp as Gecko's
version. mozilla.org branches use the same version number as the
browser-suite, e.g.:
Gecko/0.9.8
Gecko/1.0
Vendors needing to modify Gecko may only have a token named "Gecko" if
their patches are accepted upstream at mozilla.org into a branch. This
means Netscape is in the clear. If Netscape 6.5 is based off of
Mozilla 1.0 (Which includes Gecko 1.0), and doesn't modify Gecko at
all, it uses "Gecko/1.0". If Netscape needs to makes changes to Gecko,
as long as the patches are checked into mozilla.org for a gecko branch,
it uses "Gecko/1.0.$X" where $X is whatever mozilla.org assigns (so it
doesn't conflict with other branches).
Here are U-A's for Mozilla during/after a freeze/branch/release, and
for a Netscape release off that branch:
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
Gecko/ Token Idea 2:
This scheme assigns a "real" version number to Gecko on the trunk,
which possibly makes doing things like "if ($gecko_ver > x.y)" easier,
and also makes it easy to assign versions to a vendor branch off of
Mozilla's trunk, but I think this is somewhat unlikely, with
milestones being almost 1/month.
This would work much like a CVS version, and would probably need to be
tied to it so it's automatically updated. Here's 0.9.8 branching
again, all the way through a Netscape release.
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
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.
After the branch, you'll note the change counter is reset to 1 (or 0,
whatever), as it's now distinguishable because it's post 0.9.8
("0.9.8+"). This also prevents the counter from reaching astronomical
values (like the current 8 digit time stamp :).
OK. I'm *really* frickin' tired of typing. Please just agree so I
don't have to post again. :)
/jmd
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.
