quinnj opened a new issue #279:
URL: https://github.com/apache/arrow-julia/issues/279
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
```julia
] 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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
