-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-629: Add post-release tasks to dev/release/README.md #630
Conversation
This comment has been minimized.
This comment has been minimized.
@@ -172,6 +172,74 @@ $ GH_TOKEN=${YOUR_GITHUB_TOKEN} dev/release/bump_version.sh 19.0.0-SNAPSHOT | |||
It creates a feature branch and adds a commit that bumps version. This | |||
opens a pull request from the feature branch by `gh pr create`. | |||
|
|||
### Close the GitHub milestone | |||
|
|||
Close the milestone here, then open a new milestone for the next release: |
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.
What is the general rule for setting the target date of the next milestone?
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.
I don't think we really use target date. Maybe we can discuss a target release cadence? For instance, for ADBC I've been trying to hit ~6-8 weeks (it tends to slip though because I have limited time)
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.
I'm favor of predictable release pace but flexible.
For the community, it's great to know in advance when a release is planned. However, we should clearly state that what is in the release could change (depending of resources, priority, etc).
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.
I'm happy to volunteer for arrow-Java release every 6-8 weeks.
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.
Maybe we can trade off to reduce the burden/improve bus factor, but that sounds good to me.
Do you want to start a small discussion on the ML? Or if we're in agreement here then let's just go with it.
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.
Sure. I think it makes sense to discuss on the ml. Let me start a thread. Thanks !
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.
Releasing arrow-java every 6-8 weeks sounds a little bit frequent to me. Perhaps we can start with a three-month release cadence same to the mono repo in the past.
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.
Yes, let's start with quarter releases. We can always do intermediate release if needed.
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.
+1
Thanks!
What's Changed
Add instructions for undocumented post-release tasks.
Closes #629.