Hi,
This is a continuation of the "[DISCUSS] Versioning and
releases for apache/arrow components" thread:
https://lists.apache.org/thread/tvqns9d9z45mtpsqrngjyg083jdv8f1t
How about splitting Go release process from other
apache/arrow components as the first try? Here are reasons
why Go is the bes
Hi, Sutou Kouhei
The process looks good to me, and I think it's beneficial for a Go project to
have a separate repository.
I only have one suggestion:
The import path could be "github.com/apache/arrow-go" instead of
"github.com/apache/arrow-go/arrow". Since go will allow users to use
`arrow.A
Hi Kou,
Le 18/07/2024 à 11:33, Sutou Kouhei a écrit :
Here is my idea how to proceed this:
1. Extract go/ in apache/arrow to apache/arrow-go like
apache/arrow-rs
* Filter go/ related commits from apache/arrow and create
apache/arrow-go with them like we did for apache/arrow-rs
I'd like to announce an Arrow Meetup on August 13th, 2024 from 5:30PM to
7:30PM. Details can be found at [1]. All are welcome.
We will be discussing what’s going on in the Arrow community and what
community members have planned or would like to see in the coming years.
If you think you can make
My thoughts:
> * Go doesn't depend on other components such as C++
> * Go has some active PMC member (Matt) and committer (Joel)
> * Could you become a release manager for Go?
I'd happily be the release manager for the Go implementation.
> Here is my idea how to proceed this:
>
> 1. Extract go
> If we shift the Go lib to a new/different import
path we'll end up with the same problem where people will rely on older
versions and an incorrect path.
Major version upgrades already require changing the import paths by
increasing the version. The proposed change would require everyone to go
th
Part of the goal of splitting out the release processes is that we'd be
able to do minor version releases more frequently instead of major version
releases.
The general convention in the Go community is to include a major version
"v#" in the import path for all major versions past v1 so that if th
As Boolean is already in the arrow type system I think it might be worth
asking the question as to whether this should be an extension type or a
first class type.
Given what I think of the last discussion on the trade-offs [1], I think
there is room for debate here, since Boolean is not currently
I think it would confuse implementors of the spec and people implementing
kernels way too much. “the bool Arrow type” should probably not start
meaning two different things.
—
Felipe
On Fri, 19 Jul 2024 at 01:26 Micah Kornfield wrote:
> As Boolean is already in the arrow type system I think it
