Skip to content

release: 5.3.0 - #16

Closed
stainless-app[bot] wants to merge 6 commits into
mainfrom
release-please--branches--main--changes--next
Closed

release: 5.3.0#16
stainless-app[bot] wants to merge 6 commits into
mainfrom
release-please--branches--main--changes--next

Conversation

@stainless-app

@stainless-app stainless-app Bot commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Automated Release PR

5.2.1 (2026-08-20)

Full Changelog: v5.2.0...v5.2.1

Features

  • bootstrap: repo-driven STLC pipeline (8bd21c0)

Bug Fixes

  • ci: serialize release-please, ff main, drop prerelease (332dcb7)

This pull request is managed by Stainless's GitHub App.

The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.

For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.

🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions

lutz-grex and others added 6 commits August 20, 2026 10:25
Replace the hosted-Stainless release step with community
googleapis/release-please-action@v4, running on push to `next` (the
branch generation lands on). Requires a RELEASE_PLEASE_TOKEN PAT
secret (Contents:RW + PRs:RW) — the default GITHUB_TOKEN cannot
trigger publish-pypi.yml's release:published event.

Also widen release-doctor's PR trigger to include `next` since
release PRs now target it instead of `main`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLJNWZ5H1JM4ffk32S8bg3
Adds concurrency (group: release-please-next, no cancel-in-progress)
so overlapping pushes to next from the generator's regen+stamp
commits can't race release-please into a stale-version state.
After a release is actually created, fast-forwards main to the
released next commit using RELEASE_PLEASE_TOKEN (never a force-push:
a non-fast-forward push is rejected, not overwritten).

Also drops "versioning": "prerelease" / "prerelease": true from
release-please-config.json — that combination only made sense for
the old Stainless-fork pipeline. Confirmed from release-please source
(versioning-strategies/default.ts and prerelease.ts) that both
strategies check the same Release-As commit note identically before
computing any bump, so removing them preserves Release-As overrides
and yields clean major.minor.patch bumps for normal commits.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLJNWZ5H1JM4ffk32S8bg3
ci: self-hosted release-please on next
Release-As: 5.2.1
@stainless-app
stainless-app Bot force-pushed the release-please--branches--main--changes--next branch from 9b995d7 to 392973e Compare August 20, 2026 09:43
@stainless-app stainless-app Bot closed this Aug 20, 2026
@stainless-app
stainless-app Bot force-pushed the release-please--branches--main--changes--next branch from 392973e to 4acfcb9 Compare August 20, 2026 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant