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,76 @@ 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
+
```mermaid
204
+
%% use 8s to graph steps faster than 8s like seal/checksum that actually takes 0s
205
+
gantt
206
+
207
+
title Release process
208
+
dateFormat HH:mm
209
+
axisFormat %H:%M
210
+
211
+
Release commit : milestone, m1, 10:00,2m
212
+
213
+
section Seal
214
+
Bump release version : crit, 8s
215
+
Prevent source tampering : crit, 43s
216
+
section QA
217
+
Quality checks : crit, 2.2m
218
+
section Build
219
+
Checksum : crit, 8s
220
+
Build release artifact : crit, 39s
221
+
Seal : crit, 8s
222
+
section Release
223
+
Checksum : crit, 8s
224
+
PyPi temp credentials : crit, 8s
225
+
Publish PyPi : crit, pypi, 10:06, 29s
226
+
227
+
PyPi release : milestone, m2, 10:06,1s
193
228
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.
229
+
section Git release
230
+
Checksum : crit, after pypi, 8s
231
+
Git Tag : crit, 8s
232
+
Bump package version : crit, 8s
233
+
Create PR : crit, 8s
234
+
235
+
section Layer release
236
+
Build (x86+ARM) : crit, layer_build, 10:08, 6m
237
+
Deploy Beta : crit, layer_beta, after layer_build, 6.3m
238
+
Deploy Prod : crit, layer_prod, after layer_beta, 6.3m
239
+
240
+
Layer release : milestone, m3, 10:26,1s
241
+
242
+
section SAR release
243
+
Deploy Beta : crit, sar_beta, after layer_build, 2.2m
244
+
Deploy Prod : crit, sar_prod, after sar_beta, 2.2m
245
+
246
+
SAR release : milestone, m4, 10:18,1s
247
+
248
+
section Docs
249
+
Create PR (Layer ARN) : crit, after layer_prod, 8s
250
+
Release versioned docs : crit, 2.2m
251
+
252
+
Documentation release : milestone, m4, 10:28,1m
253
+
254
+
section Post-release
255
+
Close pending issues : crit, 8s
256
+
257
+
Release complete : milestone, m6, 10:31,2m
258
+
```
195
259
196
260
#### Drafting release notes
197
261
@@ -205,6 +269,8 @@ You'll notice we group all changes based on their [labels](#labels) like `featur
205
269
206
270
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
271
272
+
> **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.
273
+
208
274
**All looking good, what's next?**
209
275
210
276
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 +287,6 @@ Once you're happy, hit `Publish release` 🎉🎉🎉.
221
287
222
288
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
289
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
290
### Run end to end tests
227
291
228
292
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