ci: automate Packagist releases with release-please#56
Merged
Conversation
Set up tag-driven release management on main so tagged versions publish to Packagist automatically (via the existing GitHub webhook): - release-please workflow + manifest config; parses Conventional Commits from squash-merged PRs, maintains CHANGELOG.md, and cuts the tag + GitHub Release on merge of its rolling release PR - bump the plugin.php WP version header via a release-please marker block - .gitattributes export-ignore to keep tests/docs/website/CI out of the dist tarball (no per-release branch needed) - declare the php >=8.1 floor in require and refresh composer.lock - document the optional tangible/framework peer via a suggest entry Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- lint-pr-title workflow enforces Conventional Commits on PR titles so squash-merged subjects stay parseable by release-please - add a Development > Releasing docs page covering the release-please flow, the PR-title requirement, breaking-change signalling, and consumer version constraints; wire it into the Docusaurus sidebar Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Covers forcing a version (e.g. the first 1.0.0) via a Release-As footer, including the PR-title-only squash caveat: the footer must be added to the commit body in the merge dialog, not the PR title or description. Co-Authored-By: Claude Opus 4.8 (1M context) <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.
What
Sets up tag-driven release management so tagged versions of
tangible/objectpublish to Packagist automatically (the GitHub→Packagist webhook already exists from the current dev-main sync).Changes
.github/workflows/release-please.yml+release-please-config.json+.release-please-manifest.json— release-please maintains a rolling release PR. It parses Conventional Commit messages from our squash-merged PRs, updatesCHANGELOG.md, and on merge cuts the git tag + GitHub Release. No per-release branch, no manual changelog.plugin.php— wrapped the WPVersion:header in a release-please marker block so the plugin header stays in sync with the tag. The marker lines are plain docblock text that WordPress ignores..gitattributes—export-ignorefortests/,docs/,website/,.github/,phpunit.xml,Makefile,renovate.jsonso the Composer dist tarball stays lean. This replaces the idea of branching/cleaning per release — the dev-onlycomposer.jsonsections (require-dev,scripts, etc.) are ignored by consumers anyway.composer.json— declared thephp >=8.1floor inrequire; added asuggestentry documentingtangible/frameworkas an optional peer (already provided by other Tangible plugins at runtime).composer.lock— refreshed content-hash only; no dependency version changes.Notes / follow-ups
bootstrap-shain the config to the currentmainHEAD.0.0.2. Decide whether to commit to1.0.0or stay on0.xdeliberately — it changes how consumers'^constraints behave.GITHUB_TOKEN, which by default does not trigger other workflows (e.g. the PHPUnit CI won't run on the release PR itself). Since the release PR only bumps the changelog + version header, that's usually fine; if you want CI on it, we'd switch to a PAT.🤖 Generated with Claude Code