Hi Kou,
Thanks a lot for bringing this.
I'm +1 on the principle, both for splitting the Java release process and
moving the Java implementation into another repository.
We do need to find more maintainers for Arrow Java, but that is true
regardless of whether the Java implementation stays in the monorepo.
(also, I don't know if David Li would like to be described as
"Java-focused" :-))
Regards
Antoine.
Le 18/11/2024 à 08:55, Sutou Kouhei a écrit :
Hi,
This is a similar discussion to the "[DISCUSS] Split Go
release process" thread:
https://lists.apache.org/thread/fstyfvzczntt9mpnd4f0b39lzb8cxlyf
How about splitting Java release process from other
apache/arrow components like apache/arrow-go? Here are
some reasons of this proposal:
* The Java implementation is a native implementation not
bindings
* Some modules are the bindings of the C++ implementation
but we can support multiple C++ version if needed like
the R implementation does
* We can simplify apache/arrow release by splitting the Java
implementation
* We'll be able to use more minor/patch releases for the
Java implementation instead of major releases like the Go
implementation
Here is my idea how to proceed this:
1. Extract java/ in apache/arrow to apache/arrow-java like
apache/arrow-go
* Filter java/ related commits from apache/arrow and create
apache/arrow-java with them like we did for apache/arrow-go
* Remove java/ related codes from apache/arrow
2. Prepare integration test CI like apache/arrow-go does:
https://github.com/apache/arrow-go/blob/main/.github/workflows/test.yml
3. Prepare release script based on apache/arrow-go
We can reuse some release scripts in dev/release/ in
apache/arrow like we did in apache/arrow-adbc.
Cons of this idea:
* There is only one active Java focused PMC member and
committer: David Li
* We need to increase active Java focused PMC members and
committers for stable maintenance
What do you think about this?
Thanks,
