New package release process

[quinnj]

In #278, there was some brief discussion around what the new release process looks like now that the repo has been transferred. I'd like to propose the following and we can see if this will work in terms of what's typical in terms of Julia package releases and the Apache Way:

• Create a new GitHub Action: "JuliaReleaseVote", that we can call like @JuliaReleaseVote register() (similar to existing @JuliaRegistrator register()) on a specific commit in the repository when we feel like we're ready to vote on a new release
• JuliaReleaseVote will open a new Github Issue/Discussion proposing the release details:
  • The commit hash that is being proposed for the new release
  • The version number being proposed for release (patch, minor, or major)
  • Vote window timing; personally, I'd propose we do a 36-hour voting window for releases, since 72 seems excessive. Not sure if that's allowed, but I'd prefer it.
  • Instructions to install/test the proposed release source code; this is most conveniently done via instructions like

  ] add Arrow@[proposed_release_commit]
  ] test Arrow
  

  • Instructions for members to vote: +1, -1, etc.
• If the vote doesn't pass or issues are found, the vote issue/discussion is closed and commits can be made to fix/further prepare for the release; once a new release is ready, we call @JuliaReleaseVote register() again on the new commit
• If the vote does pass, we increment the Project.toml version number matching the voted proposal, commit the change, then call @JuliaRegistrator register() on the commit that incremented the version. This starts the Julia General Registry release process.
• We can then either enhance JuliaTagBot or create a new/separate GitHub Action or just a release script that uploads the final release source code to the apache bin @kou mentioned in #278.

@kou, how does this sound? One main thing missing that you mentioned in the linked PR is that typically a source tarball is uploaded at the beginning of a release vote. I'd propose we don't do that since I don't think it would serve any purpose. I'm actually not sure how you would go about testing a raw source tarball of a package easily in Julia, other than having to manually unzip, create a directory in your /.julia/dev environment, rename a bunch of things(?) because it would probably conflict with your existing Arrow package. That's why I proposed above that we provide the exact testing instructions that members can run to test the proposed release commit hash (this is all builtin to Julia's package manager to allow checking out a specific commit of a package and running tests on it).

Do you also think it's ok to use a GitHub issue/discussion for the release voting? As I mentioned elsewhere, I just find it much easier to follow when there's a centralized place I can visit to see all activity that has happened.

I know several people active in the Julia community that are very skilled with GitHub Actions and can facilitate the building of the proposed "JuliaReleaseVote" bot; I don't think it would be very complicated at all since, as proposed, it would just open a GitHub issue with the proposed instructions above.

Pinging relevant Julia folks for their thoughts on the above proposal: @jrevels, @NHDaly, @ericphanson, @omus, @tanmaykm

[jrevels]

This looks good to me, thanks for the writeup @quinnj.

Probably more of an Apache Way question than a specific arrow-julia question, but does a release vote pass even if nobody votes?

My naive assumption is that we wouldn't want to bottleneck e.g. patch releases from trusted maintainers on vote-gathering past a 36 hour timeframe, given the relatively small community of devs with eyes on this. So if 0 votes still results in "passes the vote", that seems good to me.

The version number being proposed for release (patch, minor, or major)

would the maintainer that triggered @JuliaReleaseVote pass in the intended bump , i.e. @JuliaReleaseVote register patch or @JuliaReleaseVote register("patch") or something like that?

[NHDaly]

would the maintainer that triggered @JuliaReleaseVote pass in the intended bump , i.e. @JuliaReleaseVote register patch or @JuliaReleaseVote register("patch") or something like that?

+1 to this question.

[kou]

@quinnj Thanks for proposing new release process!

It seems that this process doesn't satisfy https://www.apache.org/legal/release-policy.html (see also https://infra.apache.org/release-publishing.html ).

We should follow the release policy because https://www.apache.org/legal/release-policy.html#why . See also: https://infra.apache.org/release-publishing.html

Every Apache Software Foundation project software release must meet requirements for content , process , and publication. These requirements ensure that Apache contributors and users benefit from appropriate legal protection the ASF provides, and reflect the Foundation's goals of open, collaborative software development.

I understand that source archive is not necessary for Julia package because Julia users don't use source package. There is no problem that Julia developers test a release candidate by Git commit hash. Julia developers don't need to vote. (It will be useful to verify a release candidate but it's optional.) Apache Arrow PMC https://arrow.apache.org/committers/ need to vote. PMC members use source archive to verify license https://infra.apache.org/release-publishing.html#valid , signs https://infra.apache.org/release-publishing.html#signing and so on.

• If the vote does pass, we increment the Project.toml version number matching the voted proposal, commit the change, then call @JuliaRegistrator register() on the commit that incremented the version. This starts the Julia General Registry release process.

We need to call @JuliaRegistrator register() after vote by Apache Arrow PMC not Julia developers.

We can then either enhance JuliaTagBot or create a new/separate GitHub Action or just a release script that uploads the final release source code to the apache bin @kou mentioned in #278.

I think that we need to use a release script because we need to store OpenPGP private key and ASF password to GitHub when we use JuliaTagBot or a new GitHub Action. At least I don't want to store my OpenPGP private key and passphrase of it to GitHub... See also: https://infra.apache.org/release-signing#where

I'm actually not sure how you would go about testing a raw source tarball of a package easily in Julia, other than having to manually unzip, create a directory in your /.julia/dev environment, rename a bunch of things(?) because it would probably conflict with your existing Arrow package.

I'm sorry but I'm not familiar with Julia. How do you run tests uncommited code in normal development? Do Julia developers need to commit and run add Arrow@HASH to run test?

Do you also think it's ok to use a GitHub issue/discussion for the release voting? As I mentioned elsewhere, I just find it much easier to follow when there's a centralized place I can visit to see all activity that has happened.

Umm... https://www.apache.org/foundation/voting.html doesn't say "we must use mailing list for vote". We may be able to use GitHub issue/discussion for it. (I know you don't like mailing list but...) we need to ask this on mailing list.

[kou]

It seems that we can run test in source archive by the following:

$ wget https://github.com/apache/arrow-julia/archive/refs/tags/v2.2.0.tar.gz
$ tar xvf v2.2.0.tar.gz
$ cd arrow-julia-2.2.0
$ julia --project -e 'import Pkg; Pkg.build(); Pkg.test()'

[kiszk]

For all of the Apache projects, ASF defines the common rules for releasing the package.

As @kou refers, it would be good to read documents at https://www.apache.org/legal/release-policy.html#releases and https://www.apache.org/foundation/voting.html at first.
Then, we can think about implementing these policies in Julian community way on the same page.

[quinnj]

It seems that this process doesn't satisfy https://www.apache.org/legal/release-policy.html (see also https://infra.apache.org/release-publishing.html ).

@kou, can you clarify what specifically my proposal doesn't satisfy in the linked apache release policies? I think the only piece I specifically mentioned was different than apache policies was the generation of a source code tarball pre-release when PMC members would test then vote. I think that's still easily doable/possible in my proposal, since we can have the @JuliaReleaseVote bot prepare the source code tarball and attach it to the opened github issue/discussion when a vote is called. Then PMC members have a public, centralized place to come view the release details, download the source tarball directly, and can comment with their vote.

Additionally, I'm fine with having a release script that would upload the released tarball to the apache repository. That seems like a pretty easy/minor change in addition to my proposal above.

I would like to hopefully move this discussion along since the project is stalled out until we can solidify the new release process; in hindsight, we should have figured out all these details before donation to make the transfer more smooth.

[quinnj]

As @kou refers, it would be good to read documents at https://www.apache.org/legal/release-policy.html#releases and https://www.apache.org/foundation/voting.html at first.

Hi @kiszk, yes, I'm familiar with the apache release policies and tried to point out how they'd be satisfied in my proposal above (and in my subsequent follow up). I also tried to point out the particular points that may differ so as to invite discussion on whether certain policies are "suggestions" vs. hard requirements. For example, the apache policy says "Release votes SHOULD remain open for at least 72 hours." which to me sounds like we're able to propose an alternative time window because otherwise it seems like they would have worded it "Release votes MUST remain ...".

[kiszk]

@quinnj Thank you for your clarification. According to my personal feeling (I am not a native English speaker), this statement "Release votes SHOULD remain open for at least 72 hours." sounds like stronger than "should" to me. So, we have to follow it or could propose longer window than 72 hours. But, I overlooked this discussion. So, shorter window could depend on the PMC decision.

[jrevels]

But, I overlooked this discussion. So, shorter window could depend on the PMC decision.

Would be happy to have PMC weigh in, I think a shorter window would be healthier for the project.

[kou]

It seems that this process doesn't satisfy https://www.apache.org/legal/release-policy.html (see also https://infra.apache.org/release-publishing.html ).

@kou, can you clarify what specifically my proposal doesn't satisfy in the linked apache release policies?

Yes.

(I know that we can improve the proposal without drastic changes to satisfy the release policy.)

1. Source archive is missing for vote

https://www.apache.org/legal/release-policy.html#source-packages

Every ASF release MUST contain one or more source packages, which MUST be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools.

https://www.apache.org/legal/release-policy.html#release-approval

individuals are REQUIRED to download all signed source code packages onto their own hardware

The proposal doesn't provide "source code packages" for vote. It just provides a commit hash.

2. Signing is missing for vote

https://www.apache.org/legal/release-policy.html#release-approval

individuals are REQUIRED to download all signed source code packages onto their own hardware

validate all cryptographic signatures

The proposal doesn't provide "signed" source code packages for vote. It just provides a commit hash.

3. Vote target and released target are different

https://www.apache.org/legal/release-policy.html#release-types

Releases are packages that have been approved

The proposal changes Project.toml after vote:

If the vote does pass, we increment the Project.toml version number matching the voted proposal, commit the change

If we change something after the vote, changed source isn't approved.

I would like to hopefully move this discussion along since the project is stalled out until we can solidify the new release process; in hindsight, we should have figured out all these details before donation to make the transfer more smooth.

How about using the same release process as apache/arrow-rs as the first step? (I assumed that you think so.)

It's an established release process because apache/arrow-rs has been released 10 or more times.

We can use the apache/arrow-rs process by just porting https://github.com/apache/arrow-rs/tree/master/dev/release to apache/arrow-julia. We'll be able to release a new version sooner than implementing the proposal. If you like, I can port it.

We can improve our release process incrementally after we release a new version with the apache/arrow-rs process. We can still use JuliaTagBot after we upload the approved source package to https://downloads.apache.org/arrow/ .

[quinnj]

I think we have a pretty stream-lined package release process now; many thanks to @kou for all the help here.