Dear Joe, On Wed, Jan 19, 2011 at 7:49 AM, Joseph Boyer <joseph.g.bo...@gsk.com> wrote: > I just installed R 2.12.1, and when I went to run a few old programs with it, > nothing worked. > I got a ton of error messages saying such and such package was built before R > 2.10.0 and needed to be reinstalled. > > These were not just warning messages, but error messages that prevent the > programs from running when > they were running just fine with R 2.10.1 > > For some of those packages, such as deSolve, I can't find any recent versions > to download to correct the problem. > > So my first question is, is there a way around this error that doesn't > require actually installing recent versions of all those old packages? > I suppose I could just use R 2.10.1, but suppose at some point I want to use > both an old package and a new package that was built > under R 2.12.1 in the same program? That has happened by the way. I wanted to > use deSolve and yags. Since I don't have an old version of yags, > I had to install the current version on CRAN, and it won't work under 2.10.1.
This is not an option for your current problem, but if backwards compatibility is important, keep backups. I borrowed this idea from Debian which has stable and unstable versions. The stable ones are "frozen"---no more updates are done (not 100% true, but that is the gist). R is very well behaved about having multiple installs, so I typically install new versions in a new directory and then install all my packages again (I keep an R script for this). Once I am satisfied that everything I want to do works in the latest and greatest version of R + updated packages, I can delete the old versions, otherwise, I just keep both. Storage is available cheaply (< .05 USD per gigabyte), so unless you're installing all of CRAN, it should not cost much to keep duplicates. > > My second question is, if not, should the R developers reconsider their > strategic decision to invalidate packages just because they were built > under early versions of R? I do not believe that packages are invalidated because of their version. There are instances where old code no longer works, and some newer packages may also require more modern versions of packages because either the package maintainers know the older package versions do not work as they want, or they are unsure and unwilling to deal with the hassle. In any case, everything I have seen suggests that the R core team is very aware of compatibility issues and does as much as possible to keep R core stable and compatible. There have been quite a few discussions on the R-devel list about new features etc. that invariably include a discussion of what the ramifications of change would be and whether or not it is justified. > > I would be willing to bet that for many users, the improvements from R 2.10.1 > to R 2.12.1 are minor compared with the hassle caused by the fact > that their old programs will no longer work. > > This especially complicates application development, where the R programmer > is not the end user. > What developer is going to use R for his applications if he can't even be > sure they will work under future versions? I think many would, do, and will. Improvement and progress necessitate change (I suspect most developers are thrilled not to be stuck using paper tape in batch mode [and my sincerest condolences to those who still fondly remember and lament the loss]). The R core team is very good about giving advance warning and providing R-devel before it is officially released which allows software developers to start working with the new code and updating their programs if necessary before the latest version of R is rolled out to general users. I know it is frustrating and a hassle when something that used to work stops (I currently work with Windows 7 x64, Windows XP x32, and Debian unstable---trying to keep all three up-to-date and working similarly keeps me on my toes and if half the things I've muttered under my breath about computers at 2am actually came to pass.....), but also consider that the R core team already freely volunteer their time and (vast) skill to provide us this wonderful software. I do not think it is too much to ask that software developers and users be willing to put in some of their own time to update when there are changes and improvements to R that are, ultimately, benefiting us anyways. If it is truly too much bother and hassle for minor improvements, it may be better to only upgrade R versions at major releases (1, 2, 3, etc.). My school seems to have taken this approach and still has 1.8.1, I think, loaded on their lab computers. My $.02 (or$.05) Sincerely, Josh > > Joe Boyer > Principal Statistician > GSK Department of Statistical Sciences > 8-275-3661 > external: 610-787-3661 > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. -- Joshua Wiley Ph.D. Student, Health Psychology University of California, Los Angeles http://www.joshuawiley.com/ ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
