padpadpadpad
New CRAN release?
I've had a few people now who I've pointed towards rTPC but have had initial troubles due to CRAN being a bit outdated (missing around half the models we now have!)
Is it worthwhile doing a CRAN release to bring everything up to what seems like a relatively stable version (possibly bump to 1.1.0 given the number of extra models and increased functionality)?
If not, what would be a good milestone to set for getting a CRAN release out?
Yea it feels like a new CRAN release would be useful. Not sure we're planning any new overhauls for a while. Could just do some final checks and bump the version up? I am not very good/consistent with my versioning!
Generally speaking (the way that I do versioning), major versions are for large API changes or hugely increased functionality post-launch, minor versions are for general increased/changed functionality, patch versions are mostly fixes and small updates.
To me this is enough change for v1.1.0 :)
I'm away for 5 days from today and then at a conference, but can take a look at at least starting the process when I get back!
Me too. New purrr release has built in parallelisation so will be interesting to see if that works! Will try to find some time over the next week or two.
Yo @fwimp I could do this quite easily, shall I go ahead and get it sorted and then we can keep playing with new things such as https://github.com/padpadpadpad/rTPC/issues/77 and https://github.com/padpadpadpad/rTPC/issues/78 on the side? These seem like bigger changes that will likely take a little while given how busy we both are.
I think that sounds like a good idea. It would be good to get #77 and #78 out of the door sooner rather than later too (as I do think thy will make the package even more of a pleasure to use)
A thought: when we're including the parallel processing functions, I believe the R CMD BUILD needs to build with a maximum of 2 cores (iirc).
Checking the package should take as little CPU time as possible, as the CRAN check farm is a very limited resource and there are thousands of packages. Long-running tests and vignette code can be made optional for checking, but do ensure that the checks that are left do exercise all the features of the package.
If running a package uses multiple threads/cores it must never use more than two simultaneously: the check farm is a shared resource and will typically be running many checks simultaneously.
Examples should run for no more than a few seconds each: they are intended to exemplify to the would-be user how to use the functions in the package.
Probably a good idea to at least make that vignette optional for the check.
@fwimp this is ready to go but will maybe wait until we have the new functions and vignettes changed code wise.
Yeah I think that's a good idea. Best to get the functionality changes all packaged up rather than doing 2 cran releases in a row (I think they're not the biggest fans of submitting lots of updates)