<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 7, 2014 at 2:59 PM, Romain François <span dir="ltr"><<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>></span> wrote:</div>
<div class="gmail_quote">[...]<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Some R functions, e.g. useRcpp11(), could be written that, when run in<br>

> the package directory, clones a repository in inst/include/Rcpp, and<br>
> also updates pertinent licensing information (this package uses<br>
> Rcpp11, which is licensing under so-and-so...). Essentially they would<br>
> be nice wrappers to git. Maybe package these as part of an Rcpp11 CRAN<br>
> / GitHub release.<br>
<br>
</div>I think git subtree is the right tool.<br></blockquote><div><br></div><div>Personally, I would not make git compulsory for developers of clients, and I would just add/modify R code in Rcpp11 to download/update the clones and include them in the client. I think it is simpler than setting up git subtree, etc.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> One should expect that packages depending on Rcpp11 will still want to<br></div><div class="">

> be submitted to CRAN, and one potential problem (I know we could say<br>
> 'not our problem', but we should be good citizens) is that, if R-Core<br>
> decides to make an R API change that causes these packages to fail R<br>
> CMD check, it will be more painful for them to accept maintenance<br>
> releases from all these packages.<br></div></blockquote><div><br></div><div>They can just update to a newer embedded Rcpp11. You can keep two Rcpp11 branches alive if you want, so that users can upgrade to a bug-fix version without breaking the Rcpp11 API in their package.</div>
<div><br></div><div>Gabor</div></div></div></div>