[Rd] suggestion for R >= 3.0: computer-readable CHANGELOG

[Tobias Verbeke]

Philippe Grosjean wrote:
> Tobias Verbeke wrote:
>> Dirk Eddelbuettel wrote:
>>> On 17 April 2009 at 10:36, Duncan Murdoch wrote:
>>> | I think it would have to do more than that to be useful.  It would 
>>> need | to warn about a lack of an entry for the current version.  
>>> Otherwise | package.skeleton would create a blank one, and that would 
>>> satisfy the | check from then on.
>>> | | To recognize an entry for the current version, it would need a 
>>> standard | format.  But then, unless whoever put together the format 
>>> was willing to | do updates to the hundreds of existing files out 
>>> there, there would be a
>>> I'd say use it on a go-forward basis.
>>
>> I agree. For the ChangeLog, the GNU ChangeLog format could be used.
>> The advantage is that there are already converters available for some
>> commonly used source control management systems, such that users
>> can stick with their favorite systems and comply:
>>
>> For git:
>> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=build-aux/gitlog-to-changelog;hb=HEAD 
>>
>>
>> For Subversion:
>> http://ch.tudelft.nl/~arthur/svn2cl/
>>
>> For CVS:
>> http://www.red-bean.com/cvs2cl/
>>
>> Always willing to participate (also in converting existing files).
>>
>> Best,
>> Tobias
> 
> But that gives the information at the file level. Since there is no 
> constraint in R package to place the function in a given file (even 
> several R functions or objects can be defined in the same file), it 
> gives no useful information to track changes at the level of the functions!

I understand your point, but either (1) you rely on the succinct 
descriptions of developers in commit messages (and derive code
changes to look for) or (2) (as proposed in your original post) you
generate an overview of changes in code and need to rely on your
own interpretation of what these changes are about at a higher
level.

Having a structured, computer readable ChangeLog format (that might
just come out of an SCM or not) is IMO as interesting an objective as 
(2). If an argument is added in a new version, (2) is great, but the 
mere detection of change in code will not tell you it is a bug fix, for 
example, whereas a commit message might do so.

Just my 2 eurocents.

Best,
Tobias

> 
>>> | Could you take a look at CRAN and Bioconductor, and count how many 
>>> | packages already have a news/changelog file, and how hard it would 
>>> be to | convert them to a standard format?
>>>
>>> I can do the count for CRAN using the account we use for cran2deb 
>>> work.  I'll
>>> be travelling this weekend (yay, Boston Marathon!) so please ping me 
>>> next
>>> week if I forget to aggregate this.
>>>
>>> Dirk
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> 
>