Simon Urbanek wrote:
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
Simon Urbanek wrote:
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R version that the interfacing DLL was compiled against.
On Tue, 23 Dec 2008, Thomas Baier wrote:
Simon Urbanek wrote:
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R version that
On Dec 23, 2008, at 11:29 AM, Thomas Baier wrote:
Simon Urbanek wrote:
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R
We found out about this problem only a few days ago.
The reason is that the official binary packages were compiled with
2.8.1, but the distributed Windows binary of R was still 2.8.0.
rscproxy needs to be compiled for the correct version of R.
Now with R 2.8.1 being release officially the problem
On Dec 22, 2008, at 15:30 , Erich Neuwirth wrote:
We found out about this problem only a few days ago.
The reason is that the official binary packages were compiled with
2.8.1, but the distributed Windows binary of R was still 2.8.0.
rscproxy needs to be compiled for the correct version of R.
On Thu, 18 Dec 2008, meerman wrote:
After installing the package 'rscproxy' downloaded from the CRAN server, I
get the following error message from R 2.8.0 about a version conflict :
I see no 'error message' nor no 'confict'.
I see a *warning* which you could stop by using 2.8.1 RC or by
