include mailing_version in posthog analytics

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
mailing-dynamic-demo	✅ Ready (Inspect)	Visit Preview	Dec 9, 2022 at 0:12AM (UTC)
web-emails	✅ Ready (Inspect)	Visit Preview	Dec 9, 2022 at 0:12AM (UTC)

1 Ignored Deployment

| Name | Status | Preview | Updated | | :--- | :----- | :------ | :------ | | **web** | ⬜️ Ignored ([Inspect](https://vercel.com/sofn/web/HXtPBSp3ZJLEzY6F1wjQ2r4JfipG)) | | Dec 9, 2022 at 0:12AM (UTC) |

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 34090ad484f6d88ed094710afa70ea36a834fc38

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

| Name | Type | | ------------ | ----- | | mailing | Patch | | mailing-core | Patch | | web | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alexfarrill]

Verified:

• [x] (mailing cli) released 0.9.5-next.2, included in a demo project and the events include mailing_version:

  

• [x] (mailing frontend - dev frontend does not include posthog script)

• [x] (mailing frontend - production vercel deploy includes posthog script)

• [x] (mailing core)

[alexfarrill]

Everything is working here now, but this was a pain in the ass. Since scripts/release is getting kind of big now, some notes for a future refactor that could improve it:

• The constants that get replaced during the release process could all be one file per package, e.g. src/const/dynamicConstants.ts so we don't have to search and replace on every file and so you remember not to mess with the syntax of that file too much
• There should be some validation that each search found something to replace and that it was replaced back to the way it was before. One idea for a foolproof restore is you could use git: require a clean git status when release is run, then do your search and replace, afterwards git reset --hard (or git stash the changes, then you could inspect what the script did too)
• If the script gets much more complicated, we could rewrite it in ruby to make it easier to perform some of the above checks and to manage it