[Rd] rscproxy version conflict

[Thomas Baier]

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