Skip to content

chore: bootstrap release-please at 1.0.0 so the next release is 1.1.0 - #4

Open
toocool wants to merge 1 commit into
mainfrom
chore/release-please-manifest
Open

toocool wants to merge 1 commit into
mainfrom
chore/release-please-manifest

Conversation

@toocool

@toocool toocool commented Oct 17, 2026

Copy link
Copy Markdown
Contributor

Why

The open release PR #1 proposes 0.1.0, although pyproject.toml, __version__ and the CHANGELOG are all at 1.0.0. Release-please was running in single-package mode (release-type: python in the workflow), which works out the current version only from git tags or GitHub releases. This repo has neither (no v1.0.0 tag was ever pushed), so it treated the package as unreleased and fell back to the python strategy's initial version, 0.1.0. Merging #1 would have published a version lower than the 1.0.0 the repo already claims.

Unlike node, go and php, this repo was never bootstrapped. Those three use the same single-package workflow and have proper v* tags, so they bump correctly (2.2.0 / 1.1.0 / 1.1.0).

What this changes

  • .release-please-manifest.json sets the last released version to 1.0.0. When no tag exists, release-please treats the manifest version as the latest release and bumps from it.
  • release-please-config.json
    • bootstrap-sha is the initial commit (97e4387, the 1.0.0 content), so the changelog only covers changes made since then.
    • include-component-in-tag: false keeps tags as plain v1.1.0, the same format the other SDKs use.
    • extra-files: ["apinator/__init__.py"] makes release-please update __version__ along with pyproject.toml. The python strategy only looks in apinator-server/ and apinator_server/, so before this __version__ would have stayed at 1.0.0.
  • release.yml drops the release-type and package-name inputs. While release-type is set, the action ignores both files above.
  • apinator/__init__.py gets an # x-release-please-version marker on __version__.

Verification

I ran a release-please 16.18.0 dry run against this branch (release-pr --dry-run --target-branch=chore/release-please-manifest). It would open:

title: chore(...): release 1.1.0
## [1.1.0](https://github.com/apinator-io/sdk-python/compare/v1.0.0...v1.1.0)
### Features
* verify webhooks with the endpoint's webhook secret (#3)
### Bug Fixes / Documentation
* tests, cache-channel docs, text updates

That release would update pyproject.toml, apinator/__init__.py, CHANGELOG.md and the manifest.

Before or after merging

  • Close chore(main): release 0.1.0 #1. In manifest mode the release PR branch becomes release-please--branches--main--components--apinator-server, so chore(main): release 0.1.0 #1 (release-please--branches--main) won't be updated or closed automatically. Because it carries autorelease: pending, merging it by mistake would still tag and publish 0.1.0.
  • apinator-server is not on PyPI yet (https://pypi.org/pypi/apinator-server/json returns 404, and nothing is on TestPyPI either). 1.1.0 will be the first upload; skipping 1.0.0 on PyPI is harmless. The publish job uses trusted publishing (environment: pypi, id-token: write), so a pending publisher must be registered on PyPI first, for owner apinator-io, repo sdk-python, workflow release.yml, environment pypi. Without it, the first publish fails after the tag and GitHub release have already been created. The README and website already tell users to run pip install apinator-server, which fails today.

Nothing is published by this PR. Merging it only makes release-please reopen the release PR as 1.1.0.

Without a v1.0.0 tag or GitHub release, release-please treated the repo as
unreleased and proposed 0.1.0. A manifest at 1.0.0 (plus bootstrap-sha at the
initial commit) makes the next release a normal bump from 1.0.0: 1.1.0 for
the webhook-secret feat. Also keeps __version__ in apinator/__init__.py in
sync, which the python strategy could not find on its own.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants