On 20/03/2014, at 14:14 PM, S Ellison wrote: >> If we could all agree on a particular set >> of cran packages to be used with a certain release of R, then it doesn't >> matter >> how the 'snapshotting' gets implemented. > > This is pretty much the sticking point, though. I see no practical way of > reaching that agreement without the kind of decision authority (and effort) > that Linux distro maintainers put in to the internal consistency of each > distribution. > > CRAN doesn't try to do that; it's just a place to access packages offered by > maintainers. > > As a package maintainer, I think support for critical version dependencies in > the imports or dependency lists is a good idea that individual package > maintainers could relatively easily manage, but I think freezing CRAN as a > whole or adopting single release cycles for CRAN would be thoroughly > impractical. >
I have a feeling that this discussion has floated between two different arguments in favour of freezing: discontent with package authors who break their packages within R release cycle, and ability to reproduce old results. In the beginning the first argument was more prominent, but now the discussion has drifted to reproducing old results. I cannot see how freezing CRAN would help with package authors who do not separate development and CRAN release branches but introduce broken code, or code that breaks other packages. Freezing a broken snapshot would only mean that the situation cannot be cured before next R release, and then new breakage could be introduced. Result would be dysfunctional CRAN. I think that quite a few of the package updates are bug fixes and minor enhancements. Further, I do think that these should be "backported" to previous versions of R: users of previous version of R should also benefit from bug fixes. This also is the current CRAN policy and I think this is a good policy. Personally, I try to keep my packages in such a condition that they will also work in previous versions of R so that people do not need to upgrade R to have bug fixes in packages. The policy is the same with Linux maintainers: they do not just build a consistent release, but maintain the release by providing bug fixes. In Linux distributions, end of life equals freezing, or not providing new versions of software. Another issue is reproducing old analyses. This is a valuable thing, and sessionInfo and ability to get certain versions of package certainly are steps forward. It looks that guaranteed reproduction is a hard task, though. For instance, R 2.14.2 is the oldest version of R that I can build out of the box in my Linux desktop. I have earlier built older, even much older, R versions, but something has happened in my OS that crashes the build process. To reproduce an old analysis, I also should install an older version of my OS, then build old R and then get the old versions of packages. It is nice if the last step is made easier. Cheers, Jari Oksanen ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
