Re: please put version timestamp inside .el files

[Dan Jacobson]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> On 8 May 2001, Dan Jacobson wrote:

>> >> >> one feels unsure about the date of last change.
>> >> 
Eli> The last year in the Copyright line tells that.  If you want a more
Eli> accurate idea, look in the lisp/ChangeLog file.
>> >> 
>> >> Seems kind of bug prone from a software maintenance standpoint.
>> 
Eli> The Emacs maintenance is not based on any of these.  We use CVS, so
Eli> whenever we want to know who changed a file and when, we do a simple
Eli> "cvs log".
>> 
>> But can the average end user also do "cvs log"?

Eli> Not now (there's no anon CVS access to the development tree), but in
Eli> the future they will be able to do that.

OK, I hope so, otherwise it would be sort of like "non-open source
code"... at least as far as timestamps are concerned.

>> >> Ok, if the
>> >> changelog says on Thu May  3 03:41:39 CST 2001 Bob "Improved the
>> >> search function retracker sequence to not xxx on situation yyy", I
>> >> would still need 1/2 hour to analyze which of two similar search.el
>> >> files is the one with the improvement unless the appropriate comments
>> >> have been added to clue me in.
>> 
Eli> This situation shouldn't happen with packages bundled with Emacs.  All
Eli> you need is to compare Emacs versions: the later one holds the
Eli> ``improved'' version of any particular .el file.
>> 
>> as many users are using various emacs.rpm and emacs-el.rpm
>> distributions, it's very easy to be unsure about what .el and .elc's
>> one is using.

Eli> This should IMHO be taken up with the people who maintain these
Eli> distributions.  They shouldn't be doing this in the first place, I
Eli> think.

Correct.  But still it would be convenient to have those version
timestamps right in the .el files, as many users wouldn't know or be
ready to learn how to do remote cvs or whatever just to check a
timestamp... also it seems that would get them just the timestamp of
the latest version, not their particular version, unless they used a
even more complex command.  Therefore they would have a very hard time
in answering "oh, blorp.el from Jan 7 1999 was on an earlier place of
load-path than the version from June 1999, no wonder!".  Or, "xxxpackage had
a copy of blorp.el from Jan 2000 which was getting in the way..."

Or, one doesn't want to wait for a new emacs release before getting
some fixed .el file; just like one doesn't want to wait for a new
linux distribution release before updating a problem rpm... the rpm's
are fully time stamped not only inside the file, but even right in the
filename, so I vote the .el's could at least be time stamped [need
some kind of checksum signature too?] in the file header... the only
objection I see is that it might "look ugly", no?
-- 
http://www.geocities.com/jidanni Tel886-4-25854780 e-mail:restore .com.