@@ -46,13 +46,26 @@ enter the version number and the corresponding JIRA version ID for the release.
46
46
This version ID can be obtained from a link in the "Version" column on the
47
47
[ PHPC releases page] ( https://jira.mongodb.org/projects/PHPC?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased ) .
48
48
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.
56
69
57
70
## Upload package to PECL
58
71
@@ -75,180 +88,7 @@ in the MongoDB documentation must be updated to account for new releases. Make
75
88
sure to update both MongoDB and Language compatibility tables, as shown in
76
89
[ this pull request] ( https://github.com/mongodb/docs-ecosystem/pull/642 ) .
77
90
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
-
86
91
## Announce release
87
92
88
93
Significant release announcements should also be posted in the
89
94
[ 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