From Kurt.Hornik at wu-wien.ac.at  Fri Apr  4 22:04:43 2008
From: Kurt.Hornik at wu-wien.ac.at (Kurt Hornik)
Date: Fri, 4 Apr 2008 22:04:43 +0200
Subject: [Rd] R CMD check should check date in description
In-Reply-To: <f8e6ff050804041254v68b476d2i20369d50fc03d53e@mail.gmail.com>
References: <f8e6ff050804041205i18227c9dq41dbe5c4241b5605@mail.gmail.com>
	<18422.32988.112442.175233@fangorn.hornik.net>
	<f8e6ff050804041254v68b476d2i20369d50fc03d53e@mail.gmail.com>
Message-ID: <18422.35291.492048.512873@fangorn.hornik.net>

>>>>> hadley wickham writes:

>> I recently thought about this.  I see several issues.
>> 
>> * How can we determine if it is "old"?  Relative to the time when the
>> package was uploaded to a repository?
>> 
>> * Some developers might actually want a different date for a variety of
>> reasons ...
>> 
>> * What we currently say in R-exts is
>> 
>> The optional `Date' field gives the release date of the current
>> version of the package.  It is strongly recommended to use the
>> yyyy-mm-dd format conforming to the ISO standard.
>> 
>> Many packages do not comply with the latter (but I have some code to
>> sanitize most of these), and "release date" may be a moving target.
>> 
>> The best that I could think of is to teach R CMD build to *add* a Date
>> field if there was none.

> That sounds like a good solution to me.

Ok.  However, 2.7.0 feature freeze soon ...

> Otherwise, maybe just a message from R CMD check?  i.e. just like
> failing the codetools checks, it might be perfectly ok, but you should
> be doing it consciously, not by mistake.

I am working on that, too (e.g. a simple NOTE in case the date spec
cannot be canonicalized, etc.).  If file time stamps were realiable, we
could compare these to the given date.  This is I guess all we can do
for e.g. CRAN's daily checking (where comparing to the date the check
is run is not too useful) ...

Best
-k



[Rd] R CMD check should check date in description
Kurt Hornik