You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| internal | Changes in governance and chores (linting setup, baseline, etc.) | PR automation |
106
+
| tech-debt | Changes in tech debt ||
107
+
| customer-reference | Authorization to use company name in our documentation | Public Relations |
108
+
| community-content | Suggested content to feature in our documentation | Public Relations |
108
109
109
110
## Maintainer Responsibilities
110
111
@@ -185,13 +186,77 @@ Some examples using our initial and new RFC templates: #92, #94, #95, #991, #122
185
186
186
187
Firstly, make sure the commit history in the `develop` branch **(1)** it's up to date, **(2)** commit messages are semantic, and **(3)** commit messages have their respective area, for example `feat(logger): <change>`, `chore(ci): ...`).
187
188
188
-
**Found typos or unclear commit messages?**
189
+
**Looks good, what's next?**
189
190
190
-
Reword through rebase and push with `--force-with-lease` once you're confident. This will ensure [CHANGELOG](./CHANGELOG.md) is always clear for customers looking to understand what changed in between releases - was that a bug? what new features and for which utility?
191
+
Kickoff the `Release` workflow with the intended version - this might take around 25m-30m to complete.
191
192
192
-
**Looks good, what's next?**
193
+
Once complete, you can start drafting the release notes to let customers know **what changed and what's in it for them (a.k.a why they should care)**. We have guidelines in the release notes section so you know what good looks like.
194
+
195
+
> **NOTE**: Documentation might take a few minutes to reflect the latest version due to caching and CDN invalidations.
196
+
197
+
#### Release process visualized
198
+
199
+
Every release makes hundreds of checks, security scans, canaries and deployments - all of these are automated.
200
+
201
+
This is a close visual representation of the main steps (GitHub Actions UI should be the source of truth).
202
+
203
+
<!-- use 8s to graph steps faster than 8s like seal/checksum that actually takes 0s -->
204
+
205
+
```mermaid
206
+
gantt
207
+
208
+
title Release process
209
+
dateFormat HH:mm
210
+
axisFormat %H:%M
211
+
212
+
Release commit : milestone, m1, 10:00,2m
213
+
214
+
section Seal
215
+
Bump release version : active, 8s
216
+
Prevent source tampering : active, 43s
217
+
section QA
218
+
Quality checks : active, 2.2m
219
+
section Build
220
+
Checksum : active, 8s
221
+
Build release artifact : active, 39s
222
+
Seal : active, 8s
223
+
section Release
224
+
Checksum : active, 8s
225
+
PyPi temp credentials : active, 8s
226
+
Publish PyPi : active, pypi, 10:06, 29s
193
227
194
-
Kickoff the `Release` workflow with the intended version. Once complete, update the draft release notes within the `<human readable>` section summarizing why customers should care about this release.
228
+
PyPi release : milestone, m2, 10:06,1s
229
+
230
+
section Git release
231
+
Checksum : active, after pypi, 8s
232
+
Git Tag : active, 8s
233
+
Bump package version : active, 8s
234
+
Create PR : active, 8s
235
+
236
+
section Layer release
237
+
Build (x86+ARM) : active, layer_build, 10:08, 6m
238
+
Deploy Beta : active, layer_beta, after layer_build, 6.3m
239
+
Deploy Prod : active, layer_prod, after layer_beta, 6.3m
240
+
241
+
Layer release : milestone, m3, 10:26,1s
242
+
243
+
section SAR release
244
+
Deploy Beta : active, sar_beta, after layer_beta, 2.2m
245
+
Deploy Prod : active, sar_prod, after sar_beta, 2.2m
246
+
247
+
SAR release : milestone, m4, 10:25,1s
248
+
249
+
section Docs
250
+
Create PR (Layer ARN) : active, after layer_prod, 8s
251
+
Release versioned docs : active, 2.2m
252
+
253
+
Documentation release : milestone, m4, 10:28,1m
254
+
255
+
section Post-release
256
+
Close pending issues : active, 8s
257
+
258
+
Release complete : milestone, m6, 10:31,2m
259
+
```
195
260
196
261
#### Drafting release notes
197
262
@@ -205,6 +270,8 @@ You'll notice we group all changes based on their [labels](#labels) like `featur
205
270
206
271
Edit the respective PR title and update their [labels](#labels). Then run the [Release Drafter workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/release-drafter.yml) to update the Draft release.
207
272
273
+
> **NOTE**: This won't change the CHANGELOG as the merge commit is immutable. Don't worry about it. We'd only rewrite git history only if this can lead to confusion and we'd pair with another maintainer.
274
+
208
275
**All looking good, what's next?**
209
276
210
277
The best part comes now. Replace the placeholder `[Human readable summary of changes]` with what you'd like to communicate to customers what this release is all about. Rule of thumb: always put yourself in the customers shoes.
@@ -221,8 +288,6 @@ Once you're happy, hit `Publish release` 🎉🎉🎉.
221
288
222
289
This will kick off the [Publishing workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/release.yml) and within a few minutes you should see the latest version in PyPi, and all issues labeled as `pending-release` will be closed and notified.
223
290
224
-
> TODO: Include information to verify SAR and Lambda Layers deployment; we're still finalizing Lambda Layer automated deployment in GitHub Actions - ping @am29d when in doubt.
225
-
226
291
### Run end to end tests
227
292
228
293
E2E tests are run on every push to `develop` or manually via [run-e2e-tests workflow](https://github.com/awslabs/aws-lambda-powertools-python/actions/workflows/run-e2e-tests.yml).
0 commit comments