-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Support pre-releases in release tooling #1425
Conversation
This allows us to see the commands as they are run instead of having environment variables in them
828b6f3
to
01f2ada
Compare
After discussing with @jyemin, I've made a few changes to the release process:
Here's a table that illustrates a whole chain of pre-releases and a stable release:
As a stable non-patch release, the last release is a bit special and the commit links diverge. The bump commits for 5.2.0 were made in the 5.2.x branch, with master being bumped to 5.3.0-SNAPSHOT in alcaeus@4961f18. This gives a good history in both master and 5.2.x branches. |
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.
LGTM, but one question for the group:
As a best practice, should we always branch on creation of rc0?
@jyemin Could you please clarify the question? My understanding is that you are referring to the "For pre-releases, no maintenance is created" behavior, and want the Why do you think we should treat |
@alcaeus pointed out to me in a 1:1 that my question really applies to betas as well as rcs. The argument is that both betas and rcs are intended to be feature complete releases, just with varying level of quality and stability guarantees as a GA release. By branching on first beta or rc, it opens up the main branch for commits of new features. |
If the proposal is to create a maintenance branch for all kinds of pre-releases, then sure, let's do that. However, that would mean we need to bump up the version in the |
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.
LGTM
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.
LGTM
Pushed a commit (merge |
This adds support for pre-releases in the release tooling. For now, this considers only alpha and beta versions, but release candidates can be added as well.
Differences between stable releases and pre-releases:
Branch checks are run on the version without pre-release markers, so a pre-release for a patch release can only be created from the corresponding maintenance branch. At the same time, pre-release versions of non-patch releases can be created from the master branch, and the tooling will create the maintenance branch.
Link to a run: https://github.com/alcaeus/mongo-java-driver/actions/runs/9596715534
JAVA-5506