Skip to content

docs: require Rails releases for Ruby SDK changes #295

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dustinbyrne merged 2 commits into from
Oct 7, 2026
+9 −3
Merged

docs: require Rails releases for Ruby SDK changes #295

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1f0dedd
docs: require Rails releases for Ruby SDK changes
dustinbyrne Oct 7, 2026
3b10336
docs: qualify Rails dependency patch releases
dustinbyrne Oct 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,13 @@

This repository uses [Changesets](https://github.com/changesets/changesets) for version management and changelog generation, with GitHub Actions publishing `posthog-ruby` and `posthog-rails` to RubyGems.

The gems are versioned and released independently. Add the changeset to the package that changed (`posthog-ruby` or `posthog-rails`); if both changed, select both packages. `posthog-rails` is not bumped automatically when `posthog-ruby` changes, so Rails releases must be selected intentionally.
The gems have independent version numbers, but releases follow their dependency direction:

- A releasable change to `posthog-ruby` must include changesets for both `posthog-ruby` and `posthog-rails`. Select a Rails patch release when only its core SDK dependency changes and the update is backwards compatible, so Rails users receive the updated SDK.
- A Rails-only change needs a changeset for `posthog-rails`; it does not require a `posthog-ruby` changeset or release.
- If both packages have code changes, choose each package's release type based on its changes.

`posthog-rails` is not bumped automatically when `posthog-ruby` changes. Contributors must explicitly include it in the changeset.

## How to release

Expand All @@ -15,7 +21,7 @@ pnpm changeset
```

This will prompt you to:
- select the changed package or packages (`posthog-ruby` and/or `posthog-rails`)
- select both packages for a core Ruby change, or only `posthog-rails` for a Rails-only change
- select the release type (`patch`, `minor`, or `major`) for each package
- write a summary of the change

Expand All @@ -40,7 +46,7 @@ No release label is required. When the PR is merged to `main`, the release workf
- Publish only the packages whose versions changed
- Create package-specific git tags and GitHub releases, for example `posthog-ruby-v3.13.1` or `posthog-rails-v3.14.0`

When both packages changed, the workflow publishes `posthog-ruby` first, then `posthog-rails`, since `posthog-rails` depends on `posthog-ruby`. The Rails gemspec pins its `posthog-ruby` dependency to the exact core SDK version present in the release commit, so Rails-only releases intentionally keep using the latest core SDK version recorded on `main`.
When both packages are released, the workflow publishes `posthog-ruby` first, then `posthog-rails`, since `posthog-rails` depends on `posthog-ruby`. The Rails gemspec pins its `posthog-ruby` dependency to the exact core SDK version present in the release commit. Including a Rails changeset with each core Ruby release updates that pin in the published Rails gem; a Rails-only release uses the core SDK version already recorded on `main`.

## Manual trigger

Expand Down
Loading