Update release guidelines for automated releases by alcaeus · Pull Request #1884 · mongodb/mongo-php-library

alcaeus · 2026-04-28T12:47:11Z

Apparently I never updated the release guidelines after adding the automated release workflow. This PR fixes that oversight.

Copilot

Pull request overview

Updates the project’s release documentation to reflect the GitHub Actions–based automated release process.

Changes:

Adds guidance for updating extension/CI configuration before new minor releases.
Replaces manual tagging/branching instructions with steps for triggering the release.yml workflow.
Simplifies the release-notes publishing step to align with draft releases created by automation.

Copilot · 2026-04-28T12:51:49Z

+After bumping the extension version in composer.json, the `vars` for calling
+`compile extension` from `build-extension.yml` in the Evergreen configuration
+must be updated:


This section tells readers to update build-extension.yml, but that file is generated (.evergreen/config/generated/build/build-extension.yml explicitly says to edit the template instead). To avoid changes being overwritten, point to updating .evergreen/config/templates/build/build-extension.yml (and regenerating the generated config) rather than editing the generated file directly.

Copilot · 2026-04-28T12:51:50Z

+The `DRIVER_VERSION` environment variable for any GitHub Actions should also be
+set to `stable`.


Saying to set DRIVER_VERSION to stable is ambiguous/inconsistent with how the GitHub Actions setup is wired today. The composite action (.github/actions/setup/action.yml) treats driver-version as a PECL-style version string (it becomes mongodb-<driver-version>), while workflows currently set DRIVER_VERSION to values like mongodb/mongo-php-driver@v2.x with a TODO to switch to stable. Consider clarifying the expected format here (e.g., stable or a concrete PECL version like 2.3.0) and when it should be changed.

Suggested change

The `DRIVER_VERSION` environment variable for any GitHub Actions should also be

set to `stable`.

The `DRIVER_VERSION` environment variable for any GitHub Actions should use the

PECL-style version format expected by `.github/actions/setup/action.yml` (for

example, `stable` or a concrete version such as `2.3.0`), not a repository ref

such as `mongodb/mongo-php-driver@v2.x`. Update existing workflow values to that

format when those workflows are switched over to the setup action's

`driver-version` input semantics.

Copilot · 2026-04-28T12:51:50Z

+workflow page to trigger a new build. Select the correct branch (e.g. `v1.18`)
+and trigger a new run using the "Run workflow" button. In the following prompt,
+enter the version number and the corresponding JIRA version ID for the release.
+This version ID can be obtained from a link in the "Version" column on the


Branch selection guidance here doesn’t match the actual constraints in .github/workflows/release.yml: patch releases must be run from vA.B, but non-patch releases (*.0) can be run from either vA.B or vA.x (and the workflow only auto-creates the new vA.B branch when run from vA.x). Consider updating this paragraph to reflect those rules so new minor releases aren’t mistakenly run from a non-existent/incorrect branch.

Suggested change

workflow page to trigger a new build. Select the correct branch (e.g. `v1.18`)

and trigger a new run using the "Run workflow" button. In the following prompt,

enter the version number and the corresponding JIRA version ID for the release.

This version ID can be obtained from a link in the "Version" column on the

workflow page to trigger a new build. Select the correct branch and trigger a

new run using the "Run workflow" button. Patch releases must be run from the

corresponding `vA.B` branch (e.g. `v1.18`). Non-patch releases (`*.0`,

including pre-releases) may be run from either `vA.B` or `vA.x`; when run from

`vA.x`, the workflow will create the new `vA.B` branch automatically. In the

following prompt, enter the version number and the corresponding JIRA version

ID for the release. This version ID can be obtained from a link in the

"Version" column on the

Copilot · 2026-04-28T12:51:50Z

+the library version being released. For a library version x.y.z, we always
+require extension version x.y.0 as a minimum version.


The statement about extension versioning looks incorrect for this repo. The examples later in the doc use library versions like 1.20.0, but composer.json currently requires ext-mongodb: ^2.3 (extension major/minor do not match the library’s). Consider rephrasing this to describe the actual policy (e.g., bump ext-mongodb to the minimum driver version needed for the library release) instead of asserting x.y.0 based on the library version.

Suggested change

the library version being released. For a library version x.y.z, we always

require extension version x.y.0 as a minimum version.

the library version being released. Set the constraint to the minimum

extension/driver version required for that library release; do not assume that

the extension version matches the library version number.

An example is always more explicit than a sentence.

# composer.json { "require": { ... "ext-mongodb": "^2.3", ... }, }

codecov-commenter · 2026-04-28T12:53:42Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.75%. Comparing base (92f771f) to head (b658b43).
⚠️ Report is 2 commits behind head on v2.x.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##               v2.x    #1884   +/-   ##
=========================================
  Coverage     87.75%   87.75%           
  Complexity     3308     3308           
=========================================
  Files           447      447           
  Lines          6607     6607           
=========================================
  Hits           5798     5798           
  Misses          809      809

Flag	Coverage Δ
6.0-replica_set	`86.58% <ø> (ø)`
6.0-server	`82.60% <ø> (ø)`
6.0-sharded_cluster	`86.37% <ø> (ø)`
8.0-replica_set	`87.61% <ø> (ø)`
8.0-server	`83.35% <ø> (ø)`
8.0-sharded_cluster	`87.45% <ø> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

alcaeus · 2026-04-28T12:55:20Z

-These tasks can be initiated prior to tagging a new release to ensure that the
-updated content becomes accessible soon after the release is published.
+The GitHub release notes are created as a draft, and without any release
+highlights. Fill in release highlights and publish release notes.


Note to self: add a note instructing maintainers to wait for SSDLC assets to be uploaded.

GromNaN · 2026-04-29T08:50:35Z

+the library version being released. For a library version x.y.z, we always
+require extension version x.y.0 as a minimum version.


An example is always more explicit than a sentence.

# composer.json { "require": { ... "ext-mongodb": "^2.3", ... }, }

GromNaN · 2026-04-29T08:54:13Z

+* The `stable` task should specify no vars.
+* The `lowest` task should specify `EXTENSION_VERSION` with the version that
+  was just released.
+* The `next-stable` task should specify `EXTENSION_BRANCH` with the branch that
+  was just created.
+* The `next-minor` task should specify `EXTENSION_BRANCH: master`.


We discussed not having to change this by always running tests against the v2.x branch. And using #[RequiresPhpExtension('mongodb', '>= 2.3.0')] or similar check when a feature requires a newer version of the extension.
We could have kept compatibility with ext-mongodb v2.2 in the version 2.3.0 this way.

GromNaN · 2026-04-29T08:58:43Z

-
+## Trigger the release workflow
+
+Releases are done automatically through a GitHub Action. Visit the corresponding


I would be happy to see a list for each field of the workflow to trigger, to be visually equivalent:

Branch: v2.x for a new minor release, or v2.2 for a new patch release

Version: 2.3.0 for a new minor release, or 2.2.2 for a new patch release

Jira version: 54321 from Jira release page (with link)

- Fix incorrect claim that extension version matches library version; add concrete composer.json example - Point to Evergreen template file instead of generated build-extension.yml - Fix EXTENSION_BRANCH: master → v2.x - Clarify branch selection rules for patch vs. non-patch releases - Add bulleted list for workflow input fields - Add note to wait for SSDLC assets before publishing

Update release guidelines for automated releases

714bd17

alcaeus requested review from GromNaN and paulinevos April 28, 2026 12:47

alcaeus requested a review from a team as a code owner April 28, 2026 12:47

Copilot AI review requested due to automatic review settings April 28, 2026 12:47

Copilot started reviewing on behalf of alcaeus April 28, 2026 12:47 View session

Copilot AI reviewed Apr 28, 2026

View reviewed changes

alcaeus commented Apr 28, 2026

View reviewed changes

GromNaN reviewed Apr 29, 2026

View reviewed changes

alcaeus requested a review from GromNaN April 30, 2026 08:23

paulinevos approved these changes Apr 30, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update release guidelines for automated releases#1884

Update release guidelines for automated releases#1884
alcaeus wants to merge 2 commits intomongodb:v2.xfrom
alcaeus:fix-release-guideline

alcaeus commented Apr 28, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 28, 2026

Uh oh!

Copilot AI Apr 28, 2026

Uh oh!

Copilot AI Apr 28, 2026

Uh oh!

Copilot AI Apr 28, 2026

Uh oh!

GromNaN Apr 29, 2026

Uh oh!

codecov-commenter commented Apr 28, 2026 •

edited

Loading

Uh oh!

alcaeus Apr 28, 2026

Uh oh!

GromNaN Apr 29, 2026

Uh oh!

Uh oh!

GromNaN Apr 29, 2026

Uh oh!

GromNaN Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

		The `DRIVER_VERSION` environment variable for any GitHub Actions should also be
		set to `stable`.

-The `DRIVER_VERSION` environment variable for any GitHub Actions should also be
-set to `stable`.
+The `DRIVER_VERSION` environment variable for any GitHub Actions should use the
+PECL-style version format expected by `.github/actions/setup/action.yml` (for
+example, `stable` or a concrete version such as `2.3.0`), not a repository ref
+such as `mongodb/mongo-php-driver@v2.x`. Update existing workflow values to that
+format when those workflows are switched over to the setup action's
+`driver-version` input semantics.

-workflow page to trigger a new build. Select the correct branch (e.g. `v1.18`)
-and trigger a new run using the "Run workflow" button. In the following prompt,
-enter the version number and the corresponding JIRA version ID for the release.
-This version ID can be obtained from a link in the "Version" column on the
+workflow page to trigger a new build. Select the correct branch and trigger a
+new run using the "Run workflow" button. Patch releases must be run from the
+corresponding `vA.B` branch (e.g. `v1.18`). Non-patch releases (`*.0`,
+including pre-releases) may be run from either `vA.B` or `vA.x`; when run from
+`vA.x`, the workflow will create the new `vA.B` branch automatically. In the
+following prompt, enter the version number and the corresponding JIRA version
+ID for the release. This version ID can be obtained from a link in the
+"Version" column on the

		the library version being released. For a library version x.y.z, we always
		require extension version x.y.0 as a minimum version.

-the library version being released. For a library version x.y.z, we always
-require extension version x.y.0 as a minimum version.
+the library version being released. Set the constraint to the minimum
+extension/driver version required for that library release; do not assume that
+the extension version matches the library version number.


		## Trigger the release workflow

		Releases are done automatically through a GitHub Action. Visit the corresponding

Conversation

alcaeus commented Apr 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

GromNaN Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

alcaeus Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

GromNaN Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

GromNaN Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

GromNaN Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov-commenter commented Apr 28, 2026 •

edited

Loading