Releasing a new version

At the moment, we release a new version every two weeks (unless it makes sense not to!). This might change in the future.

Version numbers

Every week we up the 'minor' in major.minor.patch. At the moment, we're at version 1 for major. This will only change once we have released sufficient functionality under stage 2 of our Roadmap.

Hopefully we will not have to do many patch versions, but if between versions we discover a breaking bug, we will.

Timeline

Three days before we release, on Monday, we institute a code freeze. We branch master into release-[version] and deploy that to our production environment (app.posthog.com). Only bugfixes are allowed to be merged into this branch (and thus put on production) between Monday and the release going out. This gives us about three days to test if this release has any bugs.

Checklist

Figure out what's updated in this release

  • git checkout release-[version]
  • git log --pretty=format:%s [old-version]..head

Write up the PostHog Array blog post

Copy from PostHog Array and write up the changes into CHANGELOG.md following the structure of the previous release

  • git add CHANGELOG.md
  • git commit -m "Changelog version 1.7.0"

Update the VERSION in posthog/version.py

  • git checkout release-[version]
  • git add posthog/version.py
  • git commit -m "Bump version [version]"

Tag the version

  • git tag -a [version] -m "Version [version]"
  • git push origin head --tags

Once a new Docker image has been built (see Docker Hub, password in 1password) for the new version, open the charts repo and make the changes:

  1. Edit the two Chart files: Chart.yaml and ChartV3.yaml, in both:

    • Bump appVersion to the latest app version (same number as on the docker image).
    • Bump version (chart version) patch number, unless making big changes to the chart itself. Lesson learned: this can only be x.x.x. It can't have a fourth part.
  2. Change the docker tag in values.yaml to point to the latest tag.
  3. git commit -m 'Bump PostHog app version to 1.0.XX, release chart version 1.0.YY'
  4. git tag -a 1.0.YY -m "Version 1.0.YY"
  5. git push && git push origin head --tags

Finally to bump the latest-release docker image, log to hub.docker.com and configure a new automatic build. Set the docker tag to latest-release and the source to the tag 1.XX.YY. Delete any older tag with the same name if present and click "save & build"