Erich, the Gecko version number is pretty meaningless.
With mozilla releases, the date reflects when the build was done. Which means if you build Firefox 1.5 today, it will get a Gecko/20070410 string.
With Debian releases (except icedove), the date reflects the date for the client.mk in the source tarball, which is one of the last file upstream touches before a release. This helps having the same date for all 11 architectures (even after a binNMU) and is somehow more significant, but still not that much.
There are, at the moment, 3 main branches for Gecko-based code: MOZILLA_1_8_0_BRANCH, MOZILLA_1_8_BRANCH and HEAD. The latter currently contains Gecko 1.9 alpha, Firefox 3.0 alpha, etc., and will eventually be branched to a MOZILLA_1_9_BRANCH or something similar when going in beta. The other branches are respectively for Gecko 1.8.0.x (Firefox 1.5.0.x, Thunderbird 1.5.0.x, Seamonkey 1.0.y, Xulrunner 1.8.0.x) and Gecko 1.8.1.x (Firefox 2.0.0.x, Thunderbird 2.0.0.x (not yet released), Xulrunner 1.8.1.x).
[ In Debian Etch, we have Iceweasel 126.96.36.199 (Gecko 188.8.131.52), Iceape 1.0.8 (originally Gecko 184.108.40.206 but patched at version 220.127.116.11), Icedove 18.104.22.168 (Gecko 22.214.171.124 ; changes from version 126.96.36.199 didn't make it, but they don't affect the mailer code), and Xulrunner 188.8.131.52 (Gecko 184.108.40.206). The latter is used by kazehakase, galeon and epiphany. ]
Whenever a new security release for Firefox 1.5.0.x and other products from the Gecko 1.8.0.x branch are done, the Gecko date obviously changes, and doesn’t reflect the fact that it’s an older Gecko than that of Firefox 2.0.0.x…
Now if you take a closer look to the user agent string, you’ll see something that is actually more significant than the Gecko date, i.e. the Gecko revision, such as “rv:220.127.116.11″ in “Mozilla/5.0 (X11; U; Linux i686; ja_JP; rv:18.104.22.168) Gecko/20070324″
Both comments and pings are currently closed.