Our experience in Bioconductor is that this is a pretty hard problem. What the OP presumably wants is some guarantee that all packages on CRAN work well together. A good example is when Rcpp was updated, it broke other packages (quick note: The Rcpp developers do a incredible amount of work to deal with this; it is almost impossible to not have a few days of chaos). Ensuring this is not a trivial task, and it requires some buy-in both from the "repository" and from the developers.
For Bioconductor it is even harder as the dependency graph of Bioconductor is much more involved than the one for CRAN, where most packages depends only on a few other packages. This is why we need to do this for Bioc. Based on my experience with CRAN I am not sure I see a need for a coordinated release (or rather, I can sympathize with the need, but I don't think the effort is worth it). What would be more useful in terms of reproducibility is the capability of installing a specific version of a package from a repository using install.packages(), which would require archiving older versions in a coordinated fashion. I know CRAN archives old versions, but I am not aware if we can programmatically query the repository about this. Best, Kasper On Wed, Mar 19, 2014 at 8:52 AM, Joshua Ulrich <josh.m.ulr...@gmail.com>wrote: > On Tue, Mar 18, 2014 at 3:24 PM, Jeroen Ooms <jeroen.o...@stat.ucla.edu> > wrote: > <snip> > > ## Summary > > > > Extending the r-release cycle to CRAN seems like a solution that would > > be easy to implement. Package updates simply only get pushed to the > > r-devel branches of cran, rather than r-release and r-release-old. > > This separates development from production/use in a way that is common > > sense in most open source communities. Benefits for R include: > > > Nothing is ever as simple as it seems (especially from the perspective > of one who won't be doing the work). > > There is nothing preventing you (or anyone else) from creating > repositories that do what you suggest. Create a CRAN mirror (or more > than one) that only include the package versions you think they > should. Then have your production servers use it (them) instead of > CRAN. > > Better yet, make those repositories public. If many people like your > idea, they will use your new repositories instead of CRAN. There is > no reason to impose this change on all world-wide CRAN users. > > Best, > -- > Joshua Ulrich | about.me/joshuaulrich > FOSS Trading | www.fosstrading.com > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
