Skip to content

chore: promote staging f9cf386 to production - #535

Merged
stainless-sync[bot] merged 2 commits into
mainfrom
stlc/promote
Sep 29, 2026
Merged

stainless-sync[bot] merged 2 commits into
mainfrom
stlc/promote

Conversation

@stainless-sync

@stainless-sync stainless-sync Bot commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Automated promote from the staging trunk, opened by stlc-promote.yml.

Approve this pull request - do not click Merge. Squash and rebase both rewrite SHAs, which forks the production trunk away from staging and blocks all codegen until someone reconciles them by hand. Merge commits are disabled on this repo.

Once CI is green here and this has one approval, re-run stlc-promote.yml in the config repo. It fast-forwards main onto these exact commits, GitHub closes this pull request as merged, and the trunks stay byte-identical.

RetriggerConfidence Score: 5/5

This PR appears safe to merge through the stated promotion flow.

What we checked:

  • Stable releases still publish correctly: No. Both packages already use plain version 0.28.2, and publishing chooses a package from the unchanged tag prefix.

Summary

Release configuration no longer forces prerelease versioning for automated Python releases.

Diagram
sequenceDiagram
    participant Main as main
    participant Workflow as release-please workflow
    participant RP as release-please
    participant GitHub
    participant Publish as publish-pypi workflow
    participant PyPI

    Main->>Workflow: Push arrives
    Workflow->>RP: Run release-pr with config and manifest
    RP->>GitHub: Open or update stable release PR
    Workflow->>RP: Run github-release with config and manifest
    alt Release PR was merged
        RP->>GitHub: Create component tag and published release
        GitHub->>Publish: Send published event
        Publish->>Publish: Pick package from tag prefix
        Publish->>PyPI: Publish package
    else Release PR is still open
        RP-->>Workflow: No release yet
    end
Loading

Reviews (1) · Last reviewed commit: "Merge pull request #9 from scaleapi/fix/..."

aringuyen3 and others added 2 commits September 29, 2026 14:03
release-please-config.json carried "prerelease": true and
"versioning": "prerelease". Both have been in the file since at least
agentex-client-v0.25.0, but nothing honoured them: the hosted generator cut
python releases its own way, and 0.28.1 was cut by hand. So every python
release through 0.28.1 was a normal release.

0.28.2 was the first release cut by release-please reading this file, and it
did exactly what the file said -- it marked both GitHub Releases as
prereleases. GitHub skips prereleases when choosing the latest release, so
"latest" stayed on agentex-sdk-v0.28.1. PyPI was unaffected, since 0.28.2 is
a final version string there.

This target ships plain 0.x.y versions, which is what stainless.yml's
`publish.release.prerelease: false` says. That setting only shapes the
generated release-please workflow, though; this config is preserved from
the branch rather than regenerated, so the intent never reached it.

Dropping `versioning: prerelease` as well puts release-please on its default
strategy. With the bump-minor-pre-major and bump-patch-for-minor-pre-major
settings already here, that gives fix -> patch and feat -> minor, matching
the version history. The prerelease strategy only behaves differently when
the current version carries a prerelease suffix, which python's never has.

The two 0.28.2 releases already created were corrected directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix(release): stop marking python releases as prereleases
@stainless-sync
stainless-sync Bot merged commit f9cf386 into main Sep 29, 2026
52 checks passed
@stainless-sync
stainless-sync Bot deleted the stlc/promote branch September 29, 2026 21:23
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