Hi, > I don't want to change the import path for users > again.
I agree with you. It will be very inconvenient for users. Do you know a way to alias the import path? > 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)? I think that we should port over the same major version number. github.com/apache/arrow-go/v16 and so on should be supported too for easy migration. Thanks, -- kou In <CAH4123ZAj9YAJqsj1=yqnq3pobys4ixd92ij2pbrdqrn95j...@mail.gmail.com> "Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 15:26:09 -0400, Matt Topol <zotthewiz...@gmail.com> wrote: > 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. >>
