Skip to content
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

Merged
merged 8 commits into from
Jul 9, 2024

Conversation

alcaeus
Copy link
Member

@alcaeus alcaeus commented Jun 20, 2024

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:

  • For pre-releases, the GitHub Release is marked as such
  • For pre-releases, the version in build.gradle is set back to a snapshot of said version, e.g. 5.3.0-beta1 => 5.3.0-snapshot

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

@alcaeus alcaeus requested a review from jyemin June 20, 2024 11:40
@alcaeus alcaeus marked this pull request as draft June 20, 2024 12:55
@alcaeus
Copy link
Member Author

alcaeus commented Jun 21, 2024

After discussing with @jyemin, I've made a few changes to the release process:

  1. The version currently present in build.gradle is checked before releasing. When releasing a version A.B.C(-suffix)?, we're looking for a A.B.C-SNAPSHOT version in build.gradle - if that doesn't exist the release does not go ahead
  2. Patch releases can only be made from the corresponding maintenance branch. This could technically be removed if we assume that the version in build.gradle is always up-to-date, but the added check doesn't hurt
  3. Non-Patch releases (e.g. 5.2.0 or 6.0.0) including its pre-releases can be made from the master branch as well. For pre-releases, no maintenance is created, but when releasing a stable version a maintenance branch is created
  4. Release candidates are now also supported using the rc suffix.

Here's a table that illustrates a whole chain of pre-releases and a stable release:

Version Workflow Run Version bump Post-release version bump
5.2.0-alpha0 Link alcaeus@585f35c alcaeus@b513160
5.2.0-beta0 Link alcaeus@f8b6c2b alcaeus@534f039
5.2.0-beta1 Link alcaeus@461f48f alcaeus@c9373d7
5.2.0-rc0 Link alcaeus@b0a2c12 alcaeus@3dad9d7
5.2.0 Link alcaeus@d0cc8e8 alcaeus@682254a

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.

@alcaeus alcaeus marked this pull request as ready for review June 21, 2024 11:53
@jyemin jyemin requested review from rozza and stIncMale and removed request for stIncMale July 5, 2024 13:06
Copy link
Contributor

@jyemin jyemin left a 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?

@stIncMale
Copy link
Member

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 rc0 pre-release to be different in a way that it results in a maintenance branch creation. But that would also mean that any pre-releases following rc0 would have to be created from that maintenance branch. Such a split in the logic of pre-releases would only complicate the workflow. But maybe I misunderstand the whole thing.

Why do you think we should treat rc0 differently from other pre-releases?

@jyemin
Copy link
Contributor

jyemin commented Jul 5, 2024

@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.

@stIncMale
Copy link
Member

my question really applies to betas as well as rcs

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 master, similarly to how we do that when creating a maintenance branch for a minor or a major release.

Copy link
Member

@rozza rozza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jyemin jyemin self-requested a review July 8, 2024 15:01
Copy link
Contributor

@jyemin jyemin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@stIncMale
Copy link
Member

Pushed a commit (merge master to alcaeus:support-pre-releases b32f92b) to resolve merge conflicts.

@stIncMale stIncMale merged commit e228972 into mongodb:master Jul 9, 2024
2 of 3 checks passed
stIncMale pushed a commit to stIncMale/mongo-java-driver that referenced this pull request Jul 9, 2024
stIncMale added a commit that referenced this pull request Jul 9, 2024
Co-authored-by: Andreas Braun <andreas.braun@mongodb.com>
jyemin pushed a commit to jyemin/mongo-java-driver that referenced this pull request Sep 4, 2024
jyemin pushed a commit that referenced this pull request Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants