Hi, > My vote - for whatever it's worth - would be to do away with the > version-in-path naming convention and relying on the go version/package > system for major upgrades.
Could you share the document URL of the "go version/package system"? I'm not familiar with it. Thanks, -- kou In <CAFHtBWM2hQhtASvgDq=mnrpjv2jgerq3g0ftxnqvljfay7w...@mail.gmail.com> "Re: [DISCUSS] Split Go release process" on Thu, 18 Jul 2024 15:54:33 -0400, George Godik <ggo...@gmail.com> 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 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 > through a similar process one last time. > >> 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` > <http://github.com/apache/arrow-go/v17> or something to that end? Or > do we restart back at v1 (which I think would be confusing)? > > My vote - for whatever it's worth - would be to do away with the > version-in-path naming convention and relying on the go version/package > system for major upgrades. > > Benefits: I don't have to change import paths every 3-6months > > On Thu, Jul 18, 2024 at 3:34 PM 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> >> <http://github.com/apache/arrow-go>. >> >> The import path would still have to be `github.com/apache/arrow-go/arrow` >> <http://github.com/apache/arrow-go/arrow> >> since it would also contain the parquet implementation in ` >> github.com/apache/arrow-go/parquet` >> <http://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` >> <http://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. >> > >>
