Skip to content

docs: remind release engineers to update shared docs after each release #1123

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hln33 wants to merge 2 commits into
base: main
Choose a base branch
from
+31 −0
Open

docs: remind release engineers to update shared docs after each release #1123

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c9b09f9
docs: remind release engineers to update shared docs (#1116)
hln33 Oct 29, 2026
e00bbd6
docs: drop docs-repo check commands from the release guide
hln33 Oct 31, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,6 +119,33 @@ If additional packages are added to the monorepo in the future, follow the same

> **Note:** Automated rollout of new versions into the SDK bundled with the Lambda managed runtime relies on the release tag matching the `sdk-<version>` format. For any SDK version we want in the runtime, ensure there is a release with a tag in the exact `sdk-<version>` format (if needed, create a new release for the same commit with a correctly formatted tag).

### 3. Update the shared documentation

The release engineer owns this step for every new version release. Complete it
after the published packages are available on npm.

The shared documentation lives in
[`aws/aws-durable-execution-docs`](https://github.com/aws/aws-durable-execution-docs).
Checking version strings alone is insufficient. Review the changes in every
package released, including the testing, OTel, Telemetry Exporter, Telemetry
MCP, and ESLint plugin packages when applicable, and update the documentation
to match:

- [ ] API references and guides that describe new or changed behavior
- [ ] `examples/typescript/` snippets that use new or changed APIs
- [ ] Dependency versions, compatibility guidance, and migration instructions

Search the entire documentation repository so references are not missed:

```bash
rg -n 'durable-execution-sdk-js' docs examples/typescript
```

Open or update the documentation pull request, link this GitHub release in its
description, and follow through on review and merge. If the release needs no
documentation changes, add a note to the GitHub release stating that the
documentation review was completed and found no changes needed.

## How Publishing Works

Creating a GitHub Release triggers the [`npm-publish.yml`](.github/workflows/npm-publish.yml) workflow automatically. The workflow:
Expand Down Expand Up @@ -225,6 +252,10 @@ Before publishing a release:
- [ ] Release notes written with separate sections per package
- [ ] Tag follows the naming convention (`sdk-X.Y.Z`, `otel-X.Y.Z`, `test-X.Y.Z`, `eslint-X.Y.Z`, `telemetry-exporter-X.Y.Z`, `telemetry-mcp-X.Y.Z`, or `/`-joined)

After publishing a release:

- [ ] Shared documentation reviewed per [Update the shared documentation](#3-update-the-shared-documentation), and the docs pull request opened or "no documentation changes needed" recorded on the release

## SDK 3.x migration release order

The published minor releases use testing SDK 1.3.1 with core 2.x. This major
Expand Down
Loading