GH-21: Add release CI

[kou]

Fix GH-21

This is based on
https://github.com/apache/arrow-julia/tree/main/dev/release and https://github.com/apache/arrow-adbc/tree/main/dev/release .

Workflow:

Cut a RC:

1. Update PkgVersion in arrow/doc.go
2. Run dev/release/release_rc.sh
   1. dev/release/release_rc.sh pushes v${version}-rc${rc} tag
   2. .github/workflows/rc.yml creates apache-arrow-go-${version}.tar.gz{,.sha256,.sha512}
   3. .github/workflows/rc.yml uploads apache-arrow-go-${version}.tar.gz{,.sha256,.sha512} to GitHub Releases
   4. dev/release/release_rc.sh downloads apache-arrow-go-${version}.tar.gz from GitHub Releases
   5. dev/release/release_rc.sh signs apache-arrow-go-${version}.tar.gz as apache-arrow-go-${version}.tar.gz.asc
   6. dev/release/release_rc.sh uploads apache-arrow-go-${version}.tar.gz.asc to GitHub Releases
3. Start a vote

(GitHub Actions instead of
https://dist.apache.org/repos/dist/dev/arrow/ is used like ADBC.)

Verify a RC:

1. Run dev/release/verify_rc.sh

Release an approved RC:

1. Run dev/release/release.sh
   1. dev/release/release.sh pushes v${version} tag that refers that same commit ID as v${version}-rc${rc}
   2. dev/release/release.sh downloads apache-arrow-go-${version}.tar.gz{,.asc,.sha256,.sha512} from GitHub Actions
   3. dev/release/release.sh uploads apache-arrow-go-${version}.tar.gz{,.asc,.sha256,.sha512} to https://dist.apache.org/repos/dist/release/arrow
   4. dev/release/release.sh removes old releases from https://dist.apache.org/repos/dist/release/arrow
2. Add this release to ASF's report database: https://reporter.apache.org/addrelease.html?arrow

Follow-up tasks:

• Add support for running integration test in the verification script
• Add support for releasing a release note
• Add support for creating "v${version}"'s GitHub Releases
  • We can copy "v${version}-rc${rc}"'s GitHub Releases and adjust it for the official release

[kou]

Example RC:

• https://github.com/kou/arrow-go/releases/tag/v18.0.0-rc7
• https://github.com/kou/arrow-go/actions/runs/10826402849

[raulcd]

Some minor comments but looks good! Great work @kou I've tested the verification script locally against the uploaded RC to your fork and have validated successfully.

[raulcd]

this doesn't have to change for this PR, only when releasing, right? or do we want this to be 17.0.0 and increment on the new release?
I think we should probably continue using SNAPSHOT and just remove the SNAPSHOT bit when releasing.

[kou]

this doesn't have to change for this PR, only when releasing, right?

No.

or do we want this to be 17.0.0 and increment on the new release?

No.

My suggestions:

• Don't use -SNAPSHOT suffix for unreleased version
  • I think that it's needless because we don't create a nightly (or something) package from main
  • I think that the -SNAPSHOT suffix name is Maven convention: https://maven.apache.org/maven-release/maven-release-plugin/usage/prepare-release.html
    • If we want to use -XXX suffix for unreleased version, other name such as -dev is better
• We don't update this just after we release a new version
  • Because we can't know the next version (18.0.1? 18.1.0? 19.0.0?) just after we release a new version
• We update this just before we release a new version, when we add a new compatible feature (minor version up) or when we add an incompatible change (major version up)

[raulcd]

sounds good to me to update just before releasing

[zeroshade]

just a few nitpicks from me

[zeroshade]

why rc=100?

[kou]

I just want to use RC that is never used for normal RCs.
We can use 1000, $(date %Y%m%d) or something instead of 100 here.

[zeroshade]

ah, gotcha. $(date %Y%m%d) is probably best i think?

[kou]

OK. I'll use it.

[zeroshade]

instead of calling go clean -modcache we could try just setting the GOCACHE and GOMODCACHE env vars to point to directories in the tmpdir. That way we still get clean caches, but we don't blow up the users cache dirs.

[kou]

Removing cache isn't the main purpose of it.
It's for avoiding a permission problem. See also: apache/arrow#38222

BTW, do we need to set GOCACHE/GOMODCACHE explicitly when we set GOPATH? Can GOCACHE/GOMODCACHE be set automatically under GOPATH?

[zeroshade]

Ah gotcha.

BTW, do we need to set GOCACHE/GOMODCACHE explicitly when we set GOPATH? Can GOCACHE/GOMODCACHE be set automatically under GOPATH?

GOMODCACHE should generally be ${GOPATH}/pkg/mod, we might not need to change it explicitly since we set GOPATH.

GOCACHE can be anywhere though and typically is set to ~/.cache/go-build, if we're not running go clean -cache or otherwise cleaning the build cache, and only using go clean -modcache then we're probably fine here without issue.

[kou]

OK. Let's use go clean -modcache here.

[zeroshade]

Need to add PARQUET_TEST_BAD_DATA now as per #124

[kou]

OK. I'll add it.

[raulcd]

Thanks @kou

[zeroshade]

should this be ${{ github.ref_type }} ?

[kou]

We can omit ${{ ... }}: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idif

When you use expressions in an if conditional, you can, optionally, omit the ${{ }} expression syntax because GitHub Actions automatically evaluates the if conditional as an expression. However, this exception does not apply everywhere.

You must always use the ${{ }} expression syntax or escape with '', "", or () when the expression starts with !, since ! is reserved notation in YAML format.

[kou]

I'll merge this.