[Rprotobuf-yada] strategy for releasing (e.g. what to do about windows)

[Dirk Eddelbuettel]

On 9 November 2009 at 15:53, Romain Francois wrote:
| Now requiring Rcpp >= 0.6.7
| 
| It does not compile, but I guess this is the part you want to fix:

Exactly. Done as r90.

| In the long run, we definitely should use some class encapsulation, 
| rather than plain old SEXP stuff.
| 
| But right I'm invoking the "it works" excuse, so I'd prefer to write 
| unit tests that stress it out, and then refactor so that we know quickly 
| what we break.
| 
| That's also why I'd like to release before integrating saptarshi's proto 
| file

Ok.  Tests would indeed be good.

| I don't like or care about windows, but I want this package to be used ...
| 
| We can release saying : right now it only works on unix systems, but 
| we'd appreciate help to make a windows binary. Maybe Brian Ripley would 
| care to help us, like he does with the XML package IIRC

Works for me. RProtoBuf is for 'real' computers anyway. If someone wants it
on Windows (and someone will) they can come and offer help.  Let's not waste
time there now for a 0.1 CRAN release.

| Of course not. It does not recurse at all, it just replaces the "virtual 
| path" with the "physical path", paste with the file name and check if it 
| is there.

So if '/' is virtual, why would it not work on Windows? How can we tell
without testing?

| > I think we should respond to an env var RPROTO_TREE_TOP (or some other name)
| > and search from there.  Given a dir, we can walk it in either OS.  Doing more
| > in a portable manner is an attempt at suicide....
| 
| I'd prefer avoiding yet another environment variable.

I misunderstood the issue so the suggestion is moot. No env var needed.

Dirk

-- 
Three out of two people have difficulties with fractions.