Hi,
No objection. I'll start a vote for this.
Thanks,
--
kou
In <20240820.091745.710358189219212077@clear-code.com>
"Re: [DISCUSS] Split Go release process" on Tue, 20 Aug 2024 09:17:45 +0900
(JST),
Sutou Kouhei wrote:
> Hi,
>
>> I think we'll
vote. So a vote
before preparing github.com/apache/arrow-go will be fair.
Thanks,
--
kou
In
"Re: [DISCUSS] Split Go release process" on Mon, 19 Aug 2024 16:15:52 -0400,
Matt Topol wrote:
>> Based on 6., users need to change their import paths on
>> upgrade whether we keep
>we split Apache Arrow Go to apache/arrow-go
> >* It's for avoiding unexpected backward incompatibility
> > in users' projects
> >
> >
> > Based on 6., users need to change their import paths on
> > upgrade whether we keep using a
gt; If we use new apache/arrow-go, we will be able to reduce
> maintenance cost for apache/arrow (e.g. we can remove Go
> related scripts, CI jobs and so on from apache/arrow). Let's
> use apache/arrow-go.
>
> If nobody objects splitting Apache Arrow Go to
> apache/arrow
r apache/arrow (e.g. we can remove Go
related scripts, CI jobs and so on from apache/arrow). Let's
use apache/arrow-go.
If nobody objects splitting Apache Arrow Go to
apache/arrow-go in this week, I'll start working on this
next week. (Do we need a vote for this?)
Thanks,
--
kou
l remove most Go related CI jobs from apache/arrow. We
> will keep Go in integration test CI jobs like we do for
> apache/arrow-rs.
>
>
> Thanks,
> --
> kou
>
> In
> "Re: [DISCUSS] Split Go release process" on Fri, 19 Jul 2024 17:14:25
> +0200,
>
do for
apache/arrow-rs.
Thanks,
--
kou
In
"Re: [DISCUSS] Split Go release process" on Fri, 19 Jul 2024 17:14:25 +0200,
Raúl Cumplido wrote:
> Hi,
>
> The conversation around more frequent minor releases and version split
> per component has been a long one.
>
&g
with it.
Thanks,
--
kou
In
"Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 15:54:33 -0400,
George Godik wrote:
>> 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 an
go/v16 and so on should be
supported too for easy migration.
Thanks,
--
kou
In
"Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 15:26:09 -0400,
Matt Topol wrote:
> My thoughts:
>
>> * Go doesn't depend on other components such as C++
>> *
nks,
--
kou
In <32ec4496-e06f-47ce-ac3b-367161d5f...@python.org>
"Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 13:32:57 +0200,
Antoine Pitrou wrote:
>
> Hi Kou,
>
> Le 18/07/2024 à 11:33, Sutou Kouhei a écrit :
>> Here is my idea how to proceed
out it. I'm not familiar with Go's import
system...
Thanks,
--
kou
In <5cd7740f-b899-4075-af8d-19cd38f40...@app.fastmail.com>
"Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 17:38:55 +0800,
Xuanwo wrote:
> Hi, Sutou Kouhei
>
> The process looks
Hi,
The conversation around more frequent minor releases and version split
per component has been a long one.
I am in favour of these changes for the Go implementation because we
have several maintainers.
It might be difficult to release other implementations that do not
have the same amount of
> Extract go/ in apache/arrow to apache/arrow-go like apache/arrow-rs
I am not go maintainer and would defer to Matt and Joel on whether or
not this is more work from their end, but it does seem like Go users
have been forced to change their import paths quite a lot already and
would probably be O
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
> 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
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
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
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,
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
19 matches
Mail list logo
