-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Simplify the release process (no more build script or release branches) #281
Conversation
fedbeaf
to
707e9cb
Compare
1299255
to
ee72db4
Compare
I agree with the idea of checking in the built version |
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
…lso fails)" This reverts commit cd7944c.
@omus This is ready for another round of review. |
Bump @omus @IanButterworth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you believe in this design I'm happy to move to it. I suggest you lead the next release so that if anything goes wrong we can be reactive in fixing it.
I just cut a new release ( We can quickly revert if something breaks. |
I also updated the |
From a quick test (JuliaLang/Example.jl#80), everything seems to be working. |
Fixes #280
After this PR, the release process of this repo becomes very simple:
vMAJOR.MINOR.PATCH
tag locally (and push it).vMAJOR
tag locally (and force-push it).This is the exact same release process that is used in the
julia-actions/cache
repo1.So, by having the same release process across multiple repos, this should make things easier for maintainers.
Benefits:
Other benefits
use
able. So, if someone wants to test out a PR before it is merged, they can simply douses: julia-actions/setup-julia@name-of-pr-branch
.Footnotes
See the devdocs here: https://github.com/julia-actions/cache/blob/main/devdocs/making_a_new_release.md ↩