The gecko date string or ID is the build date, not the maturity of gecko engine

NEW
Unassigned

Status

()

--
minor
15 years ago
9 years ago

People

(Reporter: bfowler, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030728
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030728

See date string (HTTP User Agent ID) above.

This was compiled today, but checked out over a week ago. So far as I can tell,
this is mentioned in Bug 83405, but nowhere else. Fundamentally, it makes the 
ID string the dfate that gecko was last linked, which is not terribly important.

Surely the vital date is the date that the gecko sources were last committed
prior to being checked out by the builder. This should be accessible as the
$Date$ CVS keyword of some central gecko file or a CVS Tag.

Given that as hinted above, nobody has noticed this before, I assume that 
I am unaware of some vital factor, but I would have thought that this was worth
documenting.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.




Perhaps bugzilla needs a level of severity - Nitpicking.
> Surely the vital date is the date that the gecko sources were last committed
> prior to being checked out by the builder.

How is this to be updated when check-ins happen (about every hour or two)?
(Reporter)

Comment 3

15 years ago
Replying to #1.

The 'how' is by picking up the check-in date for some key source
or header file or change log for Gecko. This is a monotonically increasing
value that represents maturity.

It is not part of my suggestion that one should attempt a finer resolution
than this, in the way that the Camino nightlies have a two digit suffix
after the date string.

If you don't think that this is of value, then fair enough, but it does
mean that the string reflects the time that the Gecko library
was recompiled/linked and can be months after the date that the code
was pulled. I would have thought that this would make bug and regression
tracking troublesome.

It would most certainly be a preference of mine to have the User Agent/Build
String show the checkin date of Gecko ($Date$) and not the date that I 
personally built that library.

Perhaps not that many people compile their own Lizards and report bugs ...

If I am making an unoffical build, I am quite happy that numbers and strings
are in a separate 'number space', but I would have thought that you would have
preferred that quotable, and transmitted numbers bore a proper relationship
to reality.

Now that you have provided the discussion, you can resolve this as WONT FIX
assuming that nobody else objects.
We could have a daily auto-commit.  This would be useful for "dotting" the date
on branches, too...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

14 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041111
Firefox/0.9.1+

I looked at this again after I discovered that two check-outs and builds 
yesterday had PRODUCT-VERSION "20041111".

It seems that after the work in relation to Bug 83405 (see comments
17 et sequentes), this report is irrelevant.

It should be closed as RESOLVED FIXED (by checkins above) or RESOLVED
WORKSFORME, as the problem is gone.

(I am guessing that removing the gbdate.tstamp file will resolve the
discrepancy that brought me here I am re-spinning)
Assignee: layout → nobody
QA Contact: ian → layout
You need to log in before you can comment on or make changes to this bug.