Skip to content

Commit 2b545c3

Browse files
authored
Allow releasing pre-release versions through the release automation (#1590)
* Enable release automation to handle pre-releases * Remove obsolete section about handling merge-up pull requests * Support RC pre-release versions * Check version number before commencing release process * Simplify release instructions
1 parent 4f3400b commit 2b545c3

File tree

3 files changed

+116
-205
lines changed

3 files changed

+116
-205
lines changed

.github/workflows/release.yml

+16-24
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ on:
55
workflow_dispatch:
66
inputs:
77
version:
8-
description: "The version to be released. This is checked for consistency with the branch name and configuration"
8+
description: "The version to be released in PECL format (e.g. 1.19.1, 1.20.0beta1)"
99
required: true
1010
type: "string"
1111
jira-version-number:
@@ -53,6 +53,13 @@ jobs:
5353
contents: write
5454

5555
steps:
56+
- name: "Check version number format"
57+
run: |
58+
if ! [[ "${{ inputs.version }}" =~ ^[0-9]+\.[0-9]+\.[0-9]+((alpha|beta|RC)[0-9]+)?$ ]]; then
59+
echo '❌ Version ${{ inputs.version }} does not match expected format' >> $GITHUB_STEP_SUMMARY
60+
exit 1
61+
fi
62+
5663
- name: "Create release output"
5764
run: echo '🎬 Release process for version ${{ inputs.version }} started by @${{ github.triggering_actor }}' >> $GITHUB_STEP_SUMMARY
5865

@@ -76,31 +83,12 @@ jobs:
7683
with:
7784
php-version: "${{ matrix.php-version }}"
7885

79-
- name: "Update version information to stable release"
80-
run: ./bin/update-release-version.php to-stable
81-
82-
- name: "Read current package version"
83-
run: echo "PACKAGE_VERSION=$(./bin/update-release-version.php get-version)" >> "$GITHUB_ENV"
84-
85-
# Sanity check - the version from the input and the one determined by phongo_version.h need to be the same
86-
- name: "Check version for consistency"
87-
if: ${{ inputs.version != env.PACKAGE_VERSION }}
88-
# We exit with an error to abort the workflow. This is only run if the versions don't match
89-
run: |
90-
echo '❌ Release failed due to version mismatch: expected ${{ inputs.version }}, got ${{ env.PACKAGE_VERSION }} from code' >> $GITHUB_STEP_SUMMARY
91-
exit 1
92-
93-
#
94-
# Preliminary checks done - commence the release process
95-
#
96-
9786
- name: "Create package commit"
9887
uses: mongodb-labs/drivers-github-tools/bump-version@v2
9988
with:
10089
version: ${{ inputs.version }}
101-
# Use get-version as a dummy as a version_bump_script is required
102-
# We run the bump script manually earlier so we can sanity-check the version number and print nice output
103-
version_bump_script: "./bin/update-release-version.php get-version"
90+
# Note: this script will fail and abort if the requested version can't be released
91+
version_bump_script: "./bin/update-release-version.php release"
10492
commit_template: 'Package ${VERSION}'
10593
# Don't push changes as we're creating a second commit later
10694
push_commit: false
@@ -117,7 +105,7 @@ jobs:
117105
uses: mongodb-labs/drivers-github-tools/bump-version@v2
118106
with:
119107
version: ${{ inputs.version }}
120-
version_bump_script: "./bin/update-release-version.php to-next-patch-dev"
108+
version_bump_script: "./bin/update-release-version.php to-next-dev"
121109
commit_template: 'Back to -dev'
122110
# Don't push commit, we still need to merge up
123111
push_commit: false
@@ -155,7 +143,11 @@ jobs:
155143
EOL
156144
157145
- name: "Create draft release"
158-
run: echo "RELEASE_URL=$(gh release create ${{ inputs.version }} --target ${{ github.ref_name }} --title "${{ inputs.version }}" --notes-file release-message --draft)" >> "$GITHUB_ENV"
146+
run: |
147+
if [[ "${{ inputs.version }}" =~ (alpha|beta|RC) ]]; then
148+
PRERELEASE="--prerelease --latest=false"
149+
fi
150+
echo "RELEASE_URL=$(gh release create ${{ inputs.version }} ${PRERELEASE} --target ${{ github.ref_name }} --title "${{ inputs.version }}" --notes-file release-message --draft)" >> "$GITHUB_ENV"
159151
160152
- name: "Set summary"
161153
run: |

RELEASING.md

+20-180
Original file line numberDiff line numberDiff line change
@@ -46,13 +46,26 @@ enter the version number and the corresponding JIRA version ID for the release.
4646
This version ID can be obtained from a link in the "Version" column on the
4747
[PHPC releases page](https://jira.mongodb.org/projects/PHPC?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased).
4848

49-
The automation will then create and push the necessary commits and tag, create a
50-
draft release, and trigger the packaging builds for the newly created tag. The
51-
release is created in a draft state and can be published once the release notes
52-
have been updated.
53-
54-
Alternatively, you may follow the [manual release process](#manual-release-process)
55-
before continuing with the next section.
49+
The automation will create and push the necessary commits and tag, create a
50+
draft release, trigger the packaging builds for the newly created tag, and
51+
publish all required SSDLC assets. The release is created in a draft state and
52+
can be published once the release notes have been updated.
53+
54+
Pre-releases (alpha, beta and RC stability) can be released using the automation
55+
as well. When entering a pre-release version number, make sure to not include a
56+
dash before the stability, e.g. `1.20.0beta1` not `1.20.0-beta1`. PECL versions
57+
do not include a dash before the stability. GitHub Releases for pre-release
58+
versions will be marked as such and will not be marked as "latest" release.
59+
Examples for valid pre-release versions include:
60+
* `1.20.0alpha1`
61+
* `1.20.0beta2`
62+
* `1.20.0RC1` (note the upper-case `RC` suffix)
63+
64+
## Publish release notes
65+
66+
The GitHub release notes are created as a draft, and without any release
67+
highlights. Fill in release highlights and publish the release notes once the
68+
entire release workflow has completed.
5669

5770
## Upload package to PECL
5871

@@ -75,180 +88,7 @@ in the MongoDB documentation must be updated to account for new releases. Make
7588
sure to update both MongoDB and Language compatibility tables, as shown in
7689
[this pull request](https://github.com/mongodb/docs-ecosystem/pull/642).
7790

78-
## Handle merge-up pull request
79-
80-
After the release automation pushes changes to the stable branch the release was
81-
created from, the merge automation will create a new pull request to merge these
82-
changes into the next versioned branch. Since version changes always create a
83-
conflict, follow the "Ignoring Changes" section in the pull request to resolve
84-
the conflicts and merge the pull request once the build completes.
85-
8691
## Announce release
8792

8893
Significant release announcements should also be posted in the
8994
[MongoDB Product & Driver Announcements: Driver Releases](https://www.mongodb.com/community/forums/tags/c/announcements/driver-releases/110/php) forum.
90-
91-
## Manual release process
92-
93-
The following steps outline the manual release process. These are preserved
94-
for historical reasons and releases that are currently not supported by the
95-
release automation (e.g. beta releases). These steps are meant to be run instead
96-
of [triggering the release workflow](#trigger-the-release-workflow). The
97-
instructions assume that the steps preceding the release workflow have been
98-
completed successfully.
99-
100-
The command examples below assume that the canonical "mongodb" repository has
101-
the remote name "mongodb". You may need to adjust these commands if you've given
102-
the remote another name (e.g. "upstream"). The "origin" remote name was not used
103-
as it likely refers to your personal fork.
104-
105-
It helps to keep your own fork in sync with the "mongodb" repository (i.e. any
106-
branches and tags on the main repository should also exist in your fork). This
107-
is left as an exercise to the reader.
108-
109-
### Update version info
110-
111-
The PHP driver uses [semantic versioning](http://semver.org/). Do not break
112-
backwards compatibility in a non-major release or your users will kill you.
113-
114-
Before proceeding, ensure that the `master` branch is up-to-date with all code
115-
changes in this maintenance branch. This is important because we will later
116-
merge the ensuing release commits up to master with `--strategy=ours`, which
117-
will ignore changes from the merged commits.
118-
119-
Update the version and stability constants in `phongo_version.h` for the stable
120-
release:
121-
122-
```shell
123-
$ ./bin/update-release-version.php to-stable
124-
```
125-
126-
The Makefile targets for creating the PECL package depend on these constants, so
127-
you must rebuild the extension after updating `phongo_version.h`.
128-
129-
> [!NOTE]
130-
> If this is an alpha or beta release, the version string should include the
131-
> X.Y.Z version followed by the stability and an increment. For instance, the
132-
> first beta release in the 1.4.0 series would be "1.4.0beta1". Alpha and beta
133-
> releases use "alpha" and "beta" stability strings, respectively. Release
134-
> candidates (e.g. "1.4.0RC1") also use "beta" stability. See
135-
> [Documenting release stability and API stability](https://pear.php.net/manual/en/guide.developers.package2.stability.php)
136-
> for more information. For each change to the suffixes of
137-
> `PHP_MONGODB_VERSION`, increment the last digit of
138-
> `PHP_MONGODB_VERSION_DESC`.
139-
140-
### Build PECL package
141-
142-
Create the PECL package description file with `make package.xml`. This creates
143-
a `package.xml` file from a template. Version, author, and file information will
144-
be filled in, but release notes must be copied manually from JIRA.
145-
146-
After copying release notes, use `make package` to create the package file (e.g.
147-
`mongodb-X.Y.Z.tgz`) and ensure that it can be successfully installed:
148-
149-
```
150-
$ pecl install -f mongodb-X.Y.Z.tgz
151-
```
152-
153-
### Update version info
154-
155-
Commit the modified `phongo_version.h` file and push this change:
156-
157-
```
158-
$ git commit -m "Package X.Y.Z" phongo_version.h
159-
$ git push mongodb
160-
```
161-
162-
### Tag the release
163-
164-
Create a tag for the release and push:
165-
166-
```
167-
$ git tag -a -m "Release X.Y.Z" X.Y.Z
168-
$ git push mongodb --tags
169-
```
170-
171-
Pushing the new tag will start the packaging process which provides the PECL
172-
and Windows packages that should be attached to the release.
173-
174-
### Release PECL package
175-
176-
The PECL package may be published via the
177-
[Release Upload](https://pecl.php.net/release-upload.php) form. You will have
178-
one chance to confirm the package information after uploading.
179-
180-
### Update version info back to dev
181-
182-
After tagging, the version and stability constants in `phongo_version.h` should
183-
be updated back to development status:
184-
185-
```shell
186-
$ ./bin/update-release-version.php to-next-patch-dev
187-
```
188-
189-
Commit and push this change:
190-
191-
```
192-
$ git commit -m "Back to -dev" phongo_version.h
193-
$ git push mongodb
194-
```
195-
196-
> [!NOTE]
197-
> If this is an alpha, beta, or RC release, the version string should increment
198-
> the stability sequence instead of the patch version. For example, if the
199-
> constants were originally "1.4.0-dev" and "devel" and then changed to
200-
> "1.4.0beta1" and "beta" for the first beta release, this step would see them
201-
> ultimately changed to "1.4.0beta2-dev" and "devel".
202-
203-
### Publish release notes
204-
205-
The following template should be used for creating GitHub release notes via
206-
[this form](https://github.com/mongodb/mongo-php-driver/releases/new). The PECL
207-
package may also be attached to the release notes.
208-
209-
```markdown
210-
The PHP team is happy to announce that version X.Y.Z of the [mongodb](https://pecl.php.net/package/mongodb) PHP extension is now available on PECL.
211-
212-
**Release Highlights**
213-
214-
<one or more paragraphs describing important changes in this release>
215-
216-
A complete list of resolved issues in this release may be found in [JIRA]($JIRA_URL).
217-
218-
**Documentation**
219-
220-
Documentation is available on [PHP.net](https://php.net/set.mongodb).
221-
222-
**Installation**
223-
224-
You can either download and install the source manually, or you can install the extension with:
225-
226-
pecl install mongodb-X.Y.Z
227-
228-
or update with:
229-
230-
pecl upgrade mongodb-X.Y.Z
231-
232-
Windows binaries are attached to the GitHub release notes.
233-
```
234-
235-
> [!NOTE]
236-
> If this is an alpha or beta release, the installation examples should refer to
237-
> the exact version (e.g. "mongodb-1.8.0beta2"). This is necessary because PECL
238-
> prioritizes recent, stable releases over any stability preferences
239-
> (e.g. "mongodb-beta").
240-
241-
The URL for the list of resolved JIRA issues will need to be updated with each
242-
release. You may obtain the list from
243-
[this form](https://jira.mongodb.org/secure/ReleaseNote.jspa?projectId=12484).
244-
245-
If commits from community contributors were included in this release, append the
246-
following section:
247-
248-
```markdown
249-
**Thanks**
250-
251-
Thanks for our community contributors for X.Y.Z:
252-
253-
* [$CONTRIBUTOR_NAME](https://github.com/$GITHUB_USERNAME)
254-
```

0 commit comments

Comments
 (0)