Skip to content

RELEASING.md

Latest commit

 

History

History
53 lines (35 loc) · 2.82 KB

RELEASING.md

File metadata and controls

53 lines (35 loc) · 2.82 KB
Raw

Releasing

This repository uses Changesets for version management and changelog generation, with GitHub Actions publishing posthog-ruby and posthog-rails to RubyGems.

The gems have independent version numbers, but releases follow their dependency direction:

  • A releasable change to posthog-ruby needs a changeset for posthog-ruby. Changesets automatically includes a Rails patch release to update its core SDK dependency. A Rails patch is appropriate 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, select both and choose each package's release type based on its changes.

Changesets reads the workspace:* dependency in posthog-rails/package.json as an exact dependency on posthog-ruby and adds Rails to the release plan automatically.

How to release

1. Add a changeset

When making changes that should be released, add a changeset:

pnpm changeset

This will prompt you to:

  • select posthog-ruby for a core Ruby change, posthog-rails for a Rails-only change, or both when both packages have code changes
  • select the release type (patch, minor, or major) for each package
  • write a summary of the change

The changeset file will be created in the .changeset/ directory.

2. Create a pull request

Create a PR with your code changes and the changeset file.

3. Merge the PR

No release label is required. When the PR is merged to main, the release workflow will automatically:

  1. Check for pending changesets
  2. Notify the Client Libraries team in Slack for approval
  3. Wait for approval via the GitHub Release environment
  4. Once approved:
    • Apply changesets and bump the changed package package.json files
    • Update the changed package changelog (posthog-ruby/CHANGELOG.md or posthog-rails/CHANGELOG.md)
    • Sync package versions to the Ruby version files
    • Commit the version bump to main
    • 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 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. The automatically included Rails release updates that pin in the published Rails gem; a Rails-only release uses the core SDK version already recorded on main.

Manual trigger

You can also manually trigger the release workflow from the Actions tab, as long as there are pending changesets.