Skip to content

Latest commit

 

History

History
86 lines (60 loc) · 3.2 KB

RELEASING.md

File metadata and controls

86 lines (60 loc) · 3.2 KB
Raw

Releasing

The following steps outline the release process for both new minor versions and patch versions.

The command examples below assume that the canonical "mongodb" repository has the remote name "mongodb". You may need to adjust these commands if you've given the remote another name (e.g. "upstream"). The "origin" remote name was not used as it likely refers to your personal fork.

It helps to keep your own fork in sync with the "mongodb" repository (i.e. any branches and tags on the main repository should also exist in your fork). This is left as an exercise to the reader.

Ensure PHP version compatibility

Ensure that the test suite completes on supported versions of PHP.

Transition JIRA issues and version

All issues associated with the release version should be in the "Closed" state and have a resolution of "Fixed". Issues with other resolutions (e.g. "Duplicate", "Works as Designed") should be removed from the release version so that they do not appear in the release notes.

Check the corresponding "laravel-*.x" fix version to see if it contains any issues that are resolved as "Fixed" and should be included in this release version.

Update the version's release date and status from the Manage Versions page.

Trigger the release workflow

Releases are done automatically through a GitHub Action. Visit the corresponding Release New Version workflow page to trigger a new build. Select the correct branch (e.g. v4.5) and trigger a new run using the "Run workflow" button. In the following prompt, enter the version number.

The automation will then create and push the necessary commits and tag, and create a draft release. The release is created in a draft state and can be published once the release notes have been updated.

Branch management

Creating a maintenance branch and updating default branch name

When releasing a new major or minor version (e.g. 4.0.0), the default branch should be renamed to the next version (e.g. 4.1). Renaming the default branch using GitHub's UI ensures that all open pull request are changed to target the new version.

Once the default branch has been renamed, create the maintenance branch for the version to be released (e.g. 4.0):

$ git checkout -b X.Y
$ git push mongodb X.Y

After releasing a patch version

If this was a patch release, the maintenance branch must be merged up to the default branch (e.g. 4.1):

$ git checkout 4.1
$ git pull mongodb 4.1
$ git merge 4.0 --strategy=ours
$ git push mongodb

The --strategy=ours option ensures that all changes from the merged commits will be ignored. This is OK because we previously ensured that the 4.1 branch was up-to-date with all code changes in this maintenance branch before tagging.

Publish release notes

Use the generated release note in this form.

Release announcements should also be posted in the MongoDB Product & Driver Announcements: Driver Releases forum and shared on Twitter.