apache / arrow-go

Official Go implementation of Apache Arrow
https://arrow.apache.org/
Apache License 2.0
34 stars 6 forks source link

Push v17.0.0 tag to support migrating to apache/arrow-go without changing version #87

Closed kou closed 2 months ago

kou commented 2 months ago

If we push v17.0.0 tag that is the corresponding tag of go/v17.0.0 in apache/arrow to apache/arrow-go, users can migrate to apache/arrow-go from apache/arrow without changing version.

For example, we can do https://github.com/apache/arrow/issues/43876 before we release 18.0.0.

kou commented 2 months ago

@zeroshade Is this correct?

If we push v17.0.0 tag to apache/arrow-go, will the following change for apache/arrow work?

diff --git a/swift/CDataWGo/go.mod b/swift/CDataWGo/go.mod
index 323b5daac2..478b9273cf 100644
--- a/swift/CDataWGo/go.mod
+++ b/swift/CDataWGo/go.mod
@@ -18,7 +18,7 @@ module go-swift

 go 1.21

-require github.com/apache/arrow/go/v16 v16.1.0
+require github.com/apache/arrow-go/v17 v17.0.0

 require (
    github.com/goccy/go-json v0.10.2 // indirect
diff --git a/swift/CDataWGo/main.go b/swift/CDataWGo/main.go
index 45d1979e7e..9584e19a0c 100644
--- a/swift/CDataWGo/main.go
+++ b/swift/CDataWGo/main.go
@@ -27,10 +27,10 @@ import (
    "strconv"
    "unsafe"

-   "github.com/apache/arrow/go/v16/arrow"
-   "github.com/apache/arrow/go/v16/arrow/array"
-   "github.com/apache/arrow/go/v16/arrow/cdata"
-   "github.com/apache/arrow/go/v16/arrow/memory"
+   "github.com/apache/arrow-go/v17/arrow"
+   "github.com/apache/arrow-go/v17/arrow/array"
+   "github.com/apache/arrow-go/v17/arrow/cdata"
+   "github.com/apache/arrow-go/v17/arrow/memory"
 )

 func stringTypeFromSwift() {
kou commented 2 months ago

We may want to push v6.0.1-v16.1.0 tags too.

zeroshade commented 2 months ago

As long as we aren't deleting the old tags from the Arrow repo, we don't necessarily need to push the old tags here at all.

If we push v17.0.0 tag to apache/arrow-go, will the following change for apache/arrow work?

It wouldn't work because the go.mod file still points to the old repo and doesn't match with the new repo. Our best plan right now is to have the initial release of v18 be in this repo with the tag after we update the go.mod file.

If we do push the tags, users could use a replace directive in the go.mod to point to this repo instead of the old one (without changing the import paths) if they really want to point here instead but there really wouldn't be much of a benefit to that unless we were planning on completely deleting the tags from the monorepo.

kou commented 2 months ago

OK. I withdraw this.