chore: standardize release process#82
Merged
Merged
Conversation
Adds the shared release infrastructure (prepare-release, release-<ecosystem>, pr-title-check workflows + modules.json + generate-changelog.sh) so this repo's release flow matches the other Mixpanel SDK repositories. See: https://www.notion.so/348e0ba925628029af63c779caa835f9
Aligns the changelog-section extraction with the deployed mixpanel-android release workflow, which uses a sed range. The Python regex implementation was an accident of port-time authorship; sed is the proven approach in the gold-standard Maven Central pipeline. Uses `\@...@` as the sed address delimiter so tags containing `/` (e.g. `openfeature/v0.1.0`) don't conflict with the default `/`. Behavior is otherwise preserved: file-based release_notes.md output, fallback to "Release $TAG" placeholder when the section is missing or empty, and the two-step structure for log visibility in the workflow run.
Aligns with the Android fleet's convention of allowing `feat(all): ...`, `fix(all): ...`, `chore(all): ...` for cross-cutting changes that should appear in every module's changelog. The shared generate-changelog.sh already matches `all` (it was copied verbatim from mixpanel-android), so this regex change is the only piece needed to make the end-to-end flow accept `all`-scoped PR titles. For single-module repos, `feat(all): foo` is functionally equivalent to `feat(<only-module>): foo` — kept for fleet-wide consistency.
tylerjroach
force-pushed
the
release/standardize-release-process
branch
from
796198e to
f9cf084
Compare
Mirrors the same fix applied to mixpanel-flutter and mixpanel-react-native. Previously the generator required every commit to be scoped to either `<module>` or `all` — meaning a perfectly valid bare-titled PR like `feat: add foo` would silently drop out of the changelog despite passing the pr-title-check workflow (which accepts bare titles). Split the rule so it matches pr-title-check semantics: - feat / fix: bare, scoped to the current module, or scoped to `all` - chore: explicit scope required — bare `chore:` is the convention for changes intentionally hidden from the changelog (release prep, CI tweaks, lockfile bumps, internal docs) Other-module scopes (e.g. `feat(other):`) remain excluded from this module's changelog, as before. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rahul-mixpanel
approved these changes
May 20, 2026
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
2 participants
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
Standardizes this repo's release process to match the rest of the Mixpanel SDK fleet, per the SDK Release Process Standardization Effort.
After merge, releases follow a uniform two-step ceremony:
prepare-release.yml) — opens a release PR with the version bump, changelog section, and README header line updated.release-packagist.ymlvalidates, gates on thereleaseGitHub environment for human approval, and publishes (where applicable for this ecosystem).What's added
.github/modules.json— single source of truth for module config (paths, tag prefixes, package names).github/workflows/prepare-release.yml— manual dispatch, opens release PR.github/workflows/release-packagist.yml— tag-triggered publish workflow.github/workflows/pr-title-check.yml— conventional-commit enforcement (regex built frommodules.json).github/scripts/generate-changelog.sh— shared changelog generator (verbatim from mixpanel-android)CHANGELOG.mdper module where missinganalytics(mixpanel/mixpanel-phpon Packagist)2.12.0, notv2.12.0) — Packagist resolves both styles, but switching would break Composer constraint resolution for downstream consumersversionfield — Packagist reads from the git tag. The publish workflow has no upload step; Packagist auto-syncs via the existing GitHub webhookCHANGELOG.mdseeded from the existing changelog history embedded in the READMEHow releases work after this lands
Full ceremony, one-time setup, and PR title conventions: PHP Release Runbook
One-time setup before the first release
The runbook lists the full setup. The work that requires repo-admin access (cannot be done in this PR):
releasewith required reviewer(s)Validate PR titlecheck)Read and write permissionsandAllow GitHub Actions to create and approve pull requests(needed byprepare-release.yml'sgh pr create)Notes
fix:commit correcting a jq tag-resolution snippet (the same bug exists in the WIP Flutter/RN PRs and should be back-ported there).