Hi Jacob,
Thanks for sharing the new R version release information!
Let's re-evaluate this after the new R version release.
Thanks,
--
kou
In
"Re: [DISCUSS] Split R release process" on Tue, 4 Mar 2025 11:54:58 +0100,
Jacob Wujciak-Jens wrote:
> Hello Everyone,
>
Hi Jon,
Thanks for the note! I missed the consensus.
Thanks,
--
kou
In
"Re: [DISCUSS] Split R release process" on Mon, 3 Mar 2025 10:15:29 -0600,
Jonathan Keane wrote:
> I agree with others and don't see much upside to splitting right now.
>
> One small
t for Ubuntu 20.04:
https://github.com/apache/arrow/pull/45507#discussion_r1955436604
apache/arrow-java also faced a similar problem. The
C++-related CI jobs don't cover build options for JNI. I'll
add jobs for it:
https://github.com/apache/arrow/issues/45683
Thanks,
--
kou
In
"R
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 i
Hello Everyone,
We have discussed this in various locations but always came to the
conclusion that due to the nature of the R package as bindings to
libarrow, tracking it closely made it more convenient to stick to the
monorepo, as Neal said.
I think given the reduced development velocity/maturit
I agree with others and don't see much upside to splitting right now.
One small additional note: "The R bindings can also work with old C++
versions" is technically true, for some version (pairs), but it turns out
enforcing this is awkward, and the consensus [1] (so far) is that we
actually want t
I agree with Neal that the decoupling is less obviously desirable on the
R side. About the number of R-related CI jobs, is there still a need for
testing so many different configurations?
Le 03/03/2025 à 15:32, Neal Richardson a écrit :
Thanks for raising this, Kou. I'm personally torn on
Thanks for raising this, Kou. I'm personally torn on this because I see
some of the upsides of splitting R out, particularly at the project's state
of maturity, but it's also not as simple as Rust or Java or others we've
split out in the past because of the hard dependency on the C++ libraries.
It'
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 t
