It seems like there are currently more advantages to keeping R in the monorepo for the time being than there are advantages to splitting it out.
I'll add that the Python and R implementations routinely benefit from being in the monorepo when contributions to Arrow C++ often need to be propagated into them in some form. Having everything in one greppable repo makes this more likely to happen and this is even more important now with the reduced number of eyes on R. Thanks for raising this. On Sun, Mar 2, 2025 at 4:54 PM Sutou Kouhei <k...@clear-code.com> wrote: > > Hi, > > This is a similar discussion to the "[DISCUSS] Split Go > release process" thread[1] and the "[DISCUSS] Split Java > release process" thread[2]: > > [1] https://lists.apache.org/thread/fstyfvzczntt9mpnd4f0b39lzb8cxlyf > [2] https://lists.apache.org/thread/b99wp2f3rjhy09sx7jqvrfqjkqn9lnyy > > We've split them and they were released from separated > repositories. > > Let's discuss the next target. > > We raised JavaScript as the next candidate in the Java > discussion[3] but we may not find one or more active release > managers for JavaScript. > > [3] https://lists.apache.org/thread/bdko84zy72nlg3k82t772f7pq6zpd0sz > > I propose R as the next candidate because: > > * We have many active committers and PMC members who can > focus on R > * The current R release process is semi-separated > * In general, we release R packages to CRAN by non-trivial > release process after our monorepo release. > e.g.: https://github.com/apache/arrow/issues/45581 > * The R bindings can also work with old C++ versions > * The R bindings don't need to align with the monorepo > versioning. The R bindings can avoid major version up > per 3-4 months. > * We have many R related CI jobs. If we split the R > bindings, we can remove many CI jobs from monorepo. > > > What do you think about this? > > > Thanks, > -- > kou
