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
* fix: Avoid setting dynamic version
Version is now fixed because of sampo, so we can get rid of this
* feat: add changeset
* docs: Add new RELEASING section to README
@@ -27,13 +27,13 @@ Please see the [Python integration docs](https://posthog.com/docs/integrations/p
27
27
We recommend using [uv](https://docs.astral.sh/uv/). It's super fast.
28
28
29
29
1. Run `uv venv env` (creates virtual environment called "env")
30
-
* or `python3 -m venv env`
30
+
- or `python3 -m venv env`
31
31
2. Run `source env/bin/activate` (activates the virtual environment)
32
32
3. Run `uv sync --extra dev --extra test` (installs the package in develop mode, along with test dependencies)
33
-
* or `pip install -e ".[dev,test]"`
33
+
- or `pip install -e ".[dev,test]"`
34
34
4. you have to run `pre-commit install` to have auto linting pre commit
35
35
5. Run `make test`
36
-
1. To run a specific test do `pytest -k test_no_api_key`
36
+
6. To run a specific test do `pytest -k test_no_api_key`
37
37
38
38
## PostHog recommends `uv` so...
39
39
@@ -51,16 +51,10 @@ make test
51
51
52
52
Assuming you have a [local version of PostHog](https://posthog.com/docs/developing-locally) running, you can run `python3 example.py` to see the library in action.
53
53
54
-
### Releasing Versions
55
-
56
-
Updates are released automatically using GitHub Actions when `version.py` is updated on `master`. After bumping `version.py` in `master` and adding to `CHANGELOG.md`, the [release workflow](https://github.com/PostHog/posthog-python/blob/master/.github/workflows/release.yaml) will automatically trigger and deploy the new version.
57
-
58
-
If you need to check the latest runs or manually trigger a release, you can go to [our release workflow's page](https://github.com/PostHog/posthog-python/actions/workflows/release.yaml) and dispatch it manually, using workflow from `master`.
59
-
60
-
61
54
### Testing changes locally with the PostHog app
62
55
63
56
You can run `make prep_local`, and it'll create a new folder alongside the SDK repo one called `posthog-python-local`, which you can then import into the posthog project by changing pyproject.toml to look like this:
This'll let you build and test SDK changes fully locally, incorporating them into your local posthog app stack. It mainly takes care of the `posthog -> posthoganalytics` module renaming. You'll need to re-run `make prep_local` each time you make a change, and re-run `uv sync --active` in the posthog app project.
70
+
71
+
## Releasing
72
+
73
+
This repository uses [Sampo](https://github.com/bruits/sampo) for versioning, changelogs, and publishing to crates.io.
74
+
75
+
1. When making changes, include a changeset: `sampo add`
76
+
2. Create a PR with your changes and the changeset file
77
+
3. Add the `release` label and merge to `main`
78
+
4. Approve the release in Slack when prompted — this triggers version bump, crates.io publish, git tag, and GitHub Release
79
+
80
+
You can also trigger a release manually via the workflow's `workflow_dispatch` trigger (still requires pending changesets).
0 commit comments