Hello folks, To get it short, I cut out most of the spurious controversy, and go to the key point (and it also helps to go to sauna and then sleep well all night):
On 14/10/11 22:30 PM, "Uwe Ligges" <lig...@statistik.tu-dortmund.de> wrote: > > Also note that the package would be accepted on CRAN as is, if you > declared "parallel" as a Suggests, as far as I understand Jari. At least > binaries for Windows for old R versions will be built, since I am > checking with > _R_CHECK_FORCE_SUGGESTS_=FALSE > on Windows. Therefore, I believe (I haven't seen the package) this > discussion is meaningless anyway. This is fine and solve the problems I anticipated. I did not know about this possibility. It was not shown in R CMD check --help, nor in the usual manuals I read: it seems to be mentioned in R-ints.texi, but not in R-exts.texi nor in R-admin.texi. Although I feel well at the moment, I return to the old team: about the kind of keyword describing packages that you don't necessarily need, and which are used in style if(require(foo)) {do_something_fancy_with_foo::foo()} They are "Sugar: parallel, foo". They are not necessarily needed, if you don't have you don't necessarily even know you need them. Then about old R and new packages: many of us are in situations where we must use an old version of R. However, we can still install packages in private libraries without admin privileges. They may not be system-wide, and they can be wiped out in the next boot, or you may need to have them in your USB stick, but installing a package is rather a light operation which can be be done except in most paranoid systems. One year I burned an R installation to a CD that I distributed to the students so that they could run R in a PC class with too ancient R. In one occasion I gave students temporary usernames to my personal Linux desktop so that they could log in to my desktop from the class for one analysis (but that is in general too clumsy as Windows did not have good X11). New package versions can contain bug fixed and some enhanced functionality in addition to radical new features that require bleeding edge R. Personally, I try to keep my release versions such that they work in current, previous and future major versions of R. Currently I test the package more or less regularly in R 2.13.2 and R-to-be-2.14.0 in MacOS, and in 2.12.2 and R-to-be-2.15.0 in Linux, and I expect the release version to pass all these. The development version can fail in older R, but then we (the team) must judge if we merge such failing features to the release. Cheers, Jari Oksanen ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel