>>>>> 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
