Shantonu Sen <[EMAIL PROTECTED]> writes:
> "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.
Yup. The version number already appears in the nmh-<version> directory
name, and the release date can be gleaned from the timestamp on the tarball
as seen on mhost.com, or from the ChangeLog, so I guess there isn't much
documentative (is that a word?) value to having RELEASE_DATE and VERSION in
the top-level directory.
> >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.
Well, it could be written at `make nmhdist' time, no?
> >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).
Ah. I hadn't thought about that use of the date. It's true -- if you only
have the binaries, you wouldn't otherwise know how old a release you were
running without extra research. If people regularly look at the man page
dates to find that out, then yeah, it would be a bad idea to have the real
"Last change" date on them.
Not sure what the usual convention is on that. Looking at my 2000 release
of Apache, I see the apachectl man page says "Last change: September 1997".
The dbmmanage man page, on the other hand, says "Last change: March 1998".
My 1999 version of xemacs' man pages likewise appear to reflect the true man
page change dates. etags' man page says "Last change: 19apr1994", whereas
the xemacs man page says "Last change: 1998 January 13".
Hmm, and my 1999 version of gdb has a man page with "Last change:
4nov1991". I know the GNU stuff is kind of a special case, though, since
they made a planned move away from man-based documentation and towards info.
sendmail also appears to have per-man-page "Last change" dates. Perl does
the same, though they put the software version in the "Last change" field
and put the date to the left.
So far I'm not seeing any packages that put the package release date in the
"Last change" field, though I don't have time to look at every
multi-man-page package on my system.
Oh, speaking of that field to the left of "Last change", we still have
"MH.6.8" in there, which doesn't really make sense.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
