[toocool]

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.

Second commit: publish job hardening

• The publish job runs pytest tests/ -q before building, so a broken tree can't reach PyPI.
• It declares contents: read next to id-token: write, plus a comment saying where the trusted publisher is configured.
• pyproject.toml gains [project.urls] (site, docs, source, changelog) for the PyPI page.
• .coverage is gitignored so it can't end up in a locally built sdist.

Checked locally: uv build + twine check pass, the wheel holds only apinator/ with no runtime dependencies, tests pass on 3.9 and 3.12, and the workflow validates against the GitHub Actions schema.

Release order

1. On PyPI, add a pending trusted publisher for apinator-server: owner apinator-io, repo sdk-python, workflow release.yml, environment pypi.
2. Close chore(main): release 0.1.0 #1.
3. Merge this PR. Release-please opens a release 1.1.0 PR.
4. Merge that PR. It tags v1.1.0, creates the GitHub release, and the publish job uploads to PyPI.