You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* feat(ci/cd): Add releaser integration
* chore: Add the yaml actually
* chore: Review feedback
* chore: Add release date to the changelog entry
* chore: Ensure we do not pass the v prefix when setting a version for consistency
* chore: Ensure we do not pass the v prefix when setting a version for consistency
private-key: ${{ secrets.GH_APP_POSTHOG_PHP_RELEASER_PRIVATE_KEY }} # Secrets available only inside the 'Release' environment, requires approval from a maintainer
Please see the main [PostHog docs](https://posthog.com/docs).
4
7
5
8
Specifically, the [PHP integration](https://posthog.com/docs/integrations/php-integration) details.
@@ -27,3 +30,29 @@ Specifically, the [PHP integration](https://posthog.com/docs/integrations/php-in
27
30
1.[Download PHP](https://www.php.net/manual/en/install.php) and [Composer](https://getcomposer.org/download/)
28
31
2.`php composer.phar update` to install dependencies
29
32
3.`bin/test` to run tests (this script calls `./vendor/bin/phpunit --verbose test`)
33
+
34
+
## Releasing
35
+
36
+
Releases are semi-automated via GitHub Actions. When a PR with the `release` and a version bump label is merged to `master`, the release workflow is triggered.
37
+
38
+
You'll need an approval from a PostHog engineer. If you're an employee, you can see the request in the [#approvals-client-libraries](https://app.slack.com/client/TSS5W8YQZ/C0A3UEVDDNF) channel.
39
+
40
+
### Release Process
41
+
42
+
1.**Create your PR** with the changes you want to release
43
+
2.**Add the `release` label** to the PR
44
+
3.**Add a version bump label** that should be either `bump-patch`, `bump-minor` or `bump-major`
45
+
4.**Merge the PR** to `master`
46
+
47
+
Once merged, the following happens automatically:
48
+
49
+
1. A Slack notification is sent to the client libraries channel requesting approval
50
+
2. A maintainer approves the release in the GitHub `Release` environment
51
+
3. The version is bumped in `lib/PostHog.php` and `composer.json` based on the version label (`patch`, `minor`, or `major`, extracted from the label)
52
+
4. The `CHANGELOG.md` is updated with a link to the full changelog
53
+
5. Changes are committed and pushed to `master`
54
+
6. A git tag is created (e.g., `v1.8.0`)
55
+
7. A GitHub release is created with the changelog content
0 commit comments