From murdoch.duncan at gmail.com  Thu Jan 11 16:07:07 2018
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 11 Jan 2018 10:07:07 -0500
Subject: [Rd] R-devel Digest, Vol 179, Issue 7
In-Reply-To: <375144$8l9mcs@ironport10.mayo.edu>
References: <mailman.9.1515668402.18846.r-devel@r-project.org>
 <375144$8l9mcs@ironport10.mayo.edu>
Message-ID: <c4a7eadf-4a70-b3f1-712b-c2178cc58c48@gmail.com>

On 11/01/2018 7:17 AM, Therneau, Terry M., Ph.D. wrote:
> This is not nice.? I have easy access to the "institutional" version of R on the
> department servers, which do not track R-release all that fast (3-12 month delay, affects
> 300+ users, and at the back end of a formalized IT process), and a personal machine on
> which I track R-devel, the latter at the behest of CRAN.? Now you are asking that I track
> yet another R version just for the sake of the R CMD BUILD script??? There are other ways
> to test the new serialization code than this single file in the tarball.

I'm not asking for anything.  I'm guessing at an explanation for what 
CRAN is asking.  I'm not part of CRAN or R Core.

But it seems like 2 versions should be sufficient:  build on the 
institutional version, test on your personal machine (or on one of the 
test services like WinBuilder, R-forge, R-hub, etc.).

Duncan Murdoch

> 
> Terry T.
> 
> 
> On 01/11/2018 05:00 AM, r-devel-request at r-project.org wrote:
>> I think the message basically says:  don't do that.  You should build
>> with R-release for now.  You always need to check with R-devel, so life
>> is complicated.
>>
>> If you build with R-devel without forcing the old format, nobody using
>> R-release will be able to use your tarball.
>>
>> Eventually I guess the new format will be accepted by CRAN, but it will
>> likely be a while:  nobody expects everyone to instantly upgrade to a
>> new R release, let alone to an unreleased development version.
>>
>> Presumably that particular file (build/vignette.rds) could be
>> automatically built in the old format for now, but the new format needs
>> testing, so it makes sense to me to leave it as a default, even if it
>> makes it more complicated to submit a package to CRAN.
>>
>> Duncan Murdoch
>>
>



[Rd] R-devel Digest, Vol 179, Issue 7
Duncan Murdoch