Simon, first, I'd like to apologize, that my previous message has been sent to you directly. I have not checked the receivers list when clicking reply in my E-mail program.
Simon Urbanek wrote: > On Jan 7, 2009, at 2:05 , Thomas Baier wrote: > >> Simon, >> >> Simon Urbanek wrote: >>>> And if 2.8.0 and 2.8.1 are fully compatible, why is a warning >>>> issued, if a package built with R 2.8.1 is loaded in R 2.8.0? >>>> >>> >>> It's ok to use a package built for 2.8.0 in 2.8.1 but not vice >>> versa. It is rare, but it has happened before that a bugfix or >>> visibility change adds a symbol in x.y.1 that was not there in >>> x.y.0. Then if your package checks for that particular feature and >>> uses it you cannot use that binary with x.y.0. Again, this is >>> rather rare and you as the >> >> so this was exactly what has occured. Users having installed R 2.8.0 >> (as >> 2.8.1 has not been released then) and installing a package from CRAN >> which has been built for 2.8.1. >> >> >>> package author know about it, but to be on the safe side I was >>> recommending against that. However, as Brian pointed out this >>> happens far more often on the R function level than on the C API >>> level. >>> >>> (I know about this DLL version check because it was the first >>> change I >>> made to JRI since I wasn't willing to release Windows binary some >>> five times a year ;)). >> >> As far as I have understood Brian's message, one should just parse >> for the second '.' in the version string and omit everything >> afterwards for comparison. >> >> What I would really like to have is some new API function to check >> compatibility. If this was there both on R user level (for R language >> constructs and functions) and on C level (for packages/applications >> relying on the C API), then this would be a fine solution for >> compatiblity without issuing any warnings about wrong versions. >> > > Semantically that's not really possible since the result would always > be FALSE. The point is that if you use something that has been fixed > or added, you may run into issues since the behavior changed. R cannot > know whether that affects you package or not. Therefore it's safer to > declare patch-level releases compatible (they don't "break" existing > binaries) and everything else incompatible (as Brian was suggesting). > However, my point was that *you* can decide to exploit changes in > patch-level updates if you desire so (a practical example here is > R_SignalHandlers which was introduced (exposed) in 2.3.1 and thus a > patch-level), but in that case it is your decision not some R > incompatibility. I hope this makes clear what I was describing > earlier. In general forward binary compatibility between patch-level > versions is guaranteed and backward if you don't use features added > later on. That's true for fixes, which will break compatibity (but are required as well). If I had used R_SignalHandlers in a package, then I would have had to restrict the package to be compatible with R >= 2.3.1, not with versions before. This should be something in the DESCRIPTION file. The only thing (but code-breaking fixes) I can imagine is a compile-time check in the package, so it behaves differently for < 2.3.1 and >= 2.3.1. Best, Thomas ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
