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/ 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 > * Remove go/ related codes from apache/arrow > 2. Prepare integration test CI like apache/arrow-rs does: > https://github.com/apache/arrow-rs/blob/master/.github/workflows/integration.yml > 3. Prepare release script based on apache/arrow-julia, > apache/arrow-adbc and/or apache/arrow-flight-sql-postgresql Personally I would prefer that we do not extract it to its own separate repository purely because I don't want to change the import path for users again. We already have this issue from before we introduced the major version into the import path and shifted it up to allow for the Parquet lib in the same repository. If you look at [1] you see that there's still over 100 projects that never upgraded to v6 or higher because they are still using the old import path. 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. If we as a community decide that splitting out the implementations all into separate repositories is the best way forward, I won't hold it up by strictly hammering on this. I'm just concerned about the realities and difficulties of communicating the import path change, ensuring we don't break any consumers, and ensuring that users still end up being able to upgrade easily. > 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.Abc` directly if user imports `github.com/apache/arrow-go` <http://github.com/apache/arrow-go>. The import path would still have to be `github.com/apache/arrow-go/arrow` since it would also contain the parquet implementation in ` github.com/apache/arrow-go/parquet`. More to the point, there would be the question of whether or not we should port over the same major version number, i.e. `github.com/apache/arrow-go/v17` or something to that end? Or do we restart back at v1 (which I think would be confusing)? --Matt [1]: https://pkg.go.dev/github.com/apache/arrow/go/arrow On Thu, Jul 18, 2024 at 7:33 AM Antoine Pitrou <anto...@python.org> wrote: > > 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 > > * Remove go/ related codes from apache/arrow > > 2. Prepare integration test CI like apache/arrow-rs does: > > > https://github.com/apache/arrow-rs/blob/master/.github/workflows/integration.yml > > 3. Prepare release script based on apache/arrow-julia, > > apache/arrow-adbc and/or apache/arrow-flight-sql-postgresql > > I think this is a good idea, but I'm not part of the Go maintainers. > > > Cons of this idea: > > > > * This is a backward incompatible change > > * Users need to change their "import" to > > "github.com/apache/arrow-go/arrow" from > > "github.com/apache/arrow/go/arrow" > > Is there no way to leave some kind of alias or redirection in the > apache/arrow repository? > > Regards > > Antoine. >
