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

Claudia

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.

Paul

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






______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to