Skip to content

chore: bump version to 0.2.0.dev0 after 0.1.0 release - #906

Merged
potiuk merged 1 commit into
apache:mainfrom
potiuk:release/post-0.1.0-dev-bump
Jul 19, 2026
Merged

chore: bump version to 0.2.0.dev0 after 0.1.0 release#906
potiuk merged 1 commit into
apache:mainfrom
potiuk:release/post-0.1.0-dev-bump

Conversation

@potiuk

@potiuk potiuk commented Jul 19, 2026

Copy link
Copy Markdown
Member

Post-release version bump after Apache Magpie 0.1.0 (Step 14 of the release-management lifecycle). Opens the 0.2.0 development cycle.

Changes

Version bump

  • pyproject.toml: 0.1.00.2.0.dev0
  • uv.lock: 0.1.00.2.0.dev0 (the lock pins the package's own version; it must match pyproject.toml or uv lock --check fails CI)

Note on scope

version_manifest_files in projects/magpie/release-management-config.md currently lists only pyproject.toml, but uv.lock must move in lockstep. Suggest adding uv.lock to version_manifest_files so future post-release bumps pick it up automatically — happy to do that in a follow-up (or here, if preferred).

Opened as a draft per the release-prepare convention; ready for maintainer review.

Generated by release-prepare (magpie-release-prepare).

Post-release development-version bump (Step 14). Opens the 0.2.0
development cycle. uv.lock is included alongside pyproject.toml because
the lock pins the package's own version and must match, or uv lock
--check fails CI.
@potiuk
potiuk marked this pull request as ready for review July 19, 2026 02:49
@potiuk
potiuk merged commit 9687eb5 into apache:main Jul 19, 2026
38 checks passed
potiuk added a commit to potiuk/magpie that referenced this pull request Jul 30, 2026
Every plugin manifest claimed version `0.2.0` while `pyproject.toml` sits at
`0.2.0.dev0` (the post-0.1.0 bump, apache#906). Only `0.1.0` is tagged, so the
manifests were advertising a release that does not exist yet — and the docs
claimed they were "kept in sync with pyproject.toml", which they were not.

Make `pyproject.toml`'s `project.version` the single authority and mirror it
verbatim, `.devN` suffix included. The version now flows outward in two hops,
neither hand-edited:

  pyproject.toml
    -> .claude-plugin/plugin.json, .codex-plugin/plugin.json,
       gemini-extension.json, apm.yml
      -> the 10 generated family manifests + 11 marketplace entries

`check` fails on drift at either hop; `--fix` propagates both. A release bump
is now one edit plus one command.

Mirroring the PEP 440 string rather than translating it to a semver prerelease
(`0.2.0-dev.0`) is deliberate: `release-prepare` step 2a bumps
`version_manifest_files` by literal search/replace, which only works if every
manifest carries the identical string — and dev versions are never published to
a marketplace, so the suffix never reaches a consumer. `claude plugin validate
--strict` accepts it, and hooks/check-upgrade.sh compares versions as opaque
strings.

Version rewrites are textual substitutions, not json.dumps() round-trips, so
bumping does not reformat these hand-authored manifests (escaping em-dashes,
expanding inline objects); each write is verified by re-parsing.

Verified: `claude plugin validate . --strict` passes; simulating a bump to
0.3.0 propagates to all 25 version sites and is idempotent; prek passes
(end-of-file-fixer skipped locally — sandbox denies it a write to an unrelated
file).
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.

1 participant