ci: add release-please for automated semver + changelog#9
Merged
Conversation
Wires googleapis/release-please-action@v4 to auto-generate version
bumps + changelog from Conventional Commit messages on main.
Two release trains, both managed by the same workflow via the
packages map in release-please-config.json:
- Framework (root + framework/* + bench/* + docs/* + examples/*)
→ tag prefix 'v' (e.g. v1.0.4) — feeds existing release.yml
- Ayama showcase (apps/ayama/**)
→ tag prefix 'ayama-v' (e.g. ayama-v0.1.4) — feeds release-ayama.yml
Path scoping (`exclude-paths` for framework, package root for ayama)
makes each package release independently. A PR that touches only Ayama
won't bump the framework version, and vice-versa.
Files added:
release-please-config.json Package map + Conventional-Commit rules
.release-please-manifest.json Current versions (1.0.3 + ayama 0.1.3),
used as the bot's "point zero" — the
next release-PR will start FROM these
numbers, not from git tags. Future
versions are written here automatically
by the bot when it tags.
.github/workflows/release-please.yml The actual workflow.
How the developer flow changes:
Before:
1. Merge PRs to main
2. Manually `git tag vX.Y.Z && git push --tags`
3. release.yml builds + publishes
After:
1. Merge PRs to main with Conventional Commit messages
(feat:, fix:, BREAKING CHANGE:, chore: …)
2. release-please opens / updates a "chore(main): release vX.Y.Z" PR
with auto-generated CHANGELOG and the right semver bump
3. Review the changelog → merge the release PR
4. release-please tags the merge commit automatically
5. release.yml builds + publishes as before
Zero external dependencies, zero cost (Apache 2.0, free GitHub Actions).
GITHUB_TOKEN is provided automatically; no Google account or service
required.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3 tasks
Swately
added a commit
that referenced
this pull request
May 19, 2026
release-please was installed in PR #9 but its `extra-files` arrays were empty — it only bumped .release-please-manifest.json on each release, leaving the actual source-of-truth version constants stale: framework/_meta/include/phyriad/version.hpp stuck at 1.0.0 CMakeLists.txt stuck at 1.0.0 + rc2 apps/ayama/CMakeLists.txt stuck at 0.1.0 GitHub Releases meanwhile advanced to v1.0.3 / ayama-v0.1.3. This commit: 1. Sync all source-of-truth version files to the currently released versions (1.0.3, 0.1.3) and drop the now-stale 'rc2' prerelease tag — every public release shipped so far has been stable. 2. Add x-release-please-{major,minor,patch,version} marker comments on the four lines release-please needs to rewrite on each future release. The markers stay inert at compile time (they sit inside trailing `# ...` / `// ...` comments). 3. Create apps/ayama/core/include/ayama/version.hpp mirroring the framework's version.hpp — same MAJOR/MINOR/PATCH/MAKE_VERSION/STRING macros. Lives under ayama_core which already exposes its include dir as PUBLIC, so ayama-ui / ayama-cli / ayama-agent pick it up transitively. 4. Populate `extra-files` in release-please-config.json so the release PR rewrites all four files in lock-step with the manifest bump. After this lands, a `fix:` or `feat:` commit to main triggers a release-please PR that updates BOTH the manifest AND the in-source version constants. Merging that PR tags the commit; release.yml / release-ayama.yml then build a ZIP whose .exe knows its own version at runtime — the foundation for the upcoming "check for updates" feature in ayama-ui (PR forthcoming). Verified locally: ayama-ui.exe links clean on MinGW gcc 15.2 with the new headers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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
1 participant
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.
Summary
Wires googleapis/release-please-action@v4 — a free, open-source Conventional Commits release automation that opens / maintains a "Release PR" on `main`. When merged, the bot auto-tags (`v1.0.4` / `ayama-v0.1.4`) and the existing `release.yml` / `release-ayama.yml` workflows fire as before.
Files added
How releases work after merge
Before:
```bash
git tag v1.0.4
git push --tags # release.yml fires
```
After:
Path scoping
Cost / dependencies
Test plan
🤖 Generated with Claude Code