"Dan Harkless" writes:
>
>I'm not sure I like the new "DATE" file handling. First off, I wouldn't
>have called it "DATE", as usually all-caps files are meant to be user
>documentation, and a file called "DATE" with a bare date in it isn't too
>illuminating. True, "VERSION" is also all-caps, but at least it's clear
>what that is. If we're going to keep "DATE" an all-caps file, it should be
>called something more descriptive like "RELEASE_DATE".
It doesn't even need to be in the top-level directory, since it's
only modified by developers. It would be reasonable to move both to
config/ or something.
>I probably also would have made the file be automatically-generated, but I
>guess adding one more command to the release process isn't that big a deal.
If people download the source and compile it in two months, do we
want the date in the manpages to be when nmh was released, or built
locally? If it's dynamically generated, something would need to freeze
it at release-time to prevent version skew of on unproductive sort.
>And it kind of bothers me that the man pages claim "Last change: <DATE>". I
>guess that's techically true (for release versions of nmh, though not CVS
>versions), since we will change the nmh version number upon release, but I
>think most users would think "Last change" refers to the last meaningful
>change to the manpage, not simply the date of the last release.
Then each man page would have a different date. Would this
be confusing? Also, if someone wanted to find out how recent
their version was, how would they do it? I certainly have no problem
changing the field to something else, as long as we have 5 fields
to conform to conventions (I believe).
Shantonu
*-------------------------------------------*
|Shantonu Sen * (617)225-7269 * [EMAIL PROTECTED]|
|Electrical Engineering and Computer Science|
|Massachusetts Institute of Technology, 2002|
*-------------------------------------------*
