Repository navigation
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: pythonin the workflow), which works out the current version only from git tags or GitHub releases. This repo has neither (nov1.0.0tag 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.jsonsets the last released version to1.0.0. When no tag exists, release-please treats the manifest version as the latest release and bumps from it.release-please-config.jsonbootstrap-shais the initial commit (97e4387, the 1.0.0 content), so the changelog only covers changes made since then.include-component-in-tag: falsekeeps tags as plainv1.1.0, the same format the other SDKs use.extra-files: ["apinator/__init__.py"]makes release-please update__version__along withpyproject.toml. The python strategy only looks inapinator-server/andapinator_server/, so before this__version__would have stayed at 1.0.0.release.ymldrops therelease-typeandpackage-nameinputs. Whilerelease-typeis set, the action ignores both files above.apinator/__init__.pygets an# x-release-please-versionmarker 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:That release would update
pyproject.toml,apinator/__init__.py,CHANGELOG.mdand the manifest.Before or after merging
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 carriesautorelease: pending, merging it by mistake would still tag and publish 0.1.0.apinator-serveris not on PyPI yet (https://pypi.org/pypi/apinator-server/jsonreturns 404, and nothing is on TestPyPI either). 1.1.0 will be the first upload; skipping 1.0.0 on PyPI is harmless. Thepublishjob uses trusted publishing (environment: pypi,id-token: write), so a pending publisher must be registered on PyPI first, for ownerapinator-io, reposdk-python, workflowrelease.yml, environmentpypi. Without it, the first publish fails after the tag and GitHub release have already been created. The README and website already tell users to runpip 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.