[Rd] R-forge --as-cran

Paul Gilbert pgilbert902 at gmail.com
Fri Mar 30 17:29:06 CEST 2012

(Renamed from  "Re: [Rd] CRAN policies" because the of the 
muli-threading of that subject.)


Actually, my version numbers are year-month dates, eg 2012.3-1, although 
I don't set them automatically.

I have had some additional off-line discussion on this. The problem is this:

Now when I submit version 2012.3-1 to CRAN, any checks of that package 
on R-forge will fail, until I change the version number. This is by 
specific request of the CRAN maintainers to the R-forge maintainers, the 
reason being, understandably, that the CRAN maintainers do not like 
getting submissions without the version number changed. One implication 
of this is that I should change the R-forge version number as soon as I 
make any changes to the package, even if I am going to change it again 
before I actually release to CRAN. This seems like a reasonable 
practice, even if I have not always done that.

The case where the code on R-forge remains unchanged for some time after 
it is released to CRAN is more subtle. If R-forge does not re-run the 
checks until I make a change, as is the current situation, then the 
package will still be indicated as ok on the R-forge pkg page. However, 
when R is upgraded, I would like the checks to be re-run on all 
platforms, not just on my own testing platform. But when that is done, 
the R-forge indication is going to be that the package failed, because 
the version number is the same as on CRAN. The information I want is 
actually available on the CRAN daily check. I just need to know that 
when my package is unchanged from the version on CRAN, I should look at 
CRAN daily rather than at the R-forge result.


On 12-03-30 10:38 AM, Claudia Beleites wrote:
> Paul,
>> One of the things I have noticed with the R 2.15.0 RC and --as-cran is
>> that the I have to bump the version number of the working copy of my
> [snip]
>> I am curious how other developers approach this.
> Regardless of --as-cran I find it very useful to use the date as minor
> part of the version number (e.g. hyperSpec 0.98-20120320), which I set
> automatically.
> Claudia

More information about the R-devel mailing list