Release Nos 0.1.13

[joshuatbrown]

Production Deployment

• [x] Wait for Linda to complete UAT on a staging build
• [x] Copy this “Production Deployment” section into a GitHub ticket on our [Product Board](https://github.com/orgs/planetary-social/projects/11/views/1).
• [x] Check out the commit that has passed UAT via its tag, like vstaging-0.1.11-240. It should already have been deployed to TestFlight via a [Staging Deployment](https://www.notion.so/Staging-Deployment-04931912aa474deea54b5e6e3df0bac7?pvs=21) and passed UAT.
• [x] Create a new release branch with the current version number after the slash like git checkout -b release/x.y.z and push it to GitHub. This will trigger a production build of the app which you can monitor in the [TestFlight Release Deployment action](https://github.com/planetary-social/nos/actions/workflows/testflight-deploy.yml).
• [x] Move tickets for any changes from the UAT column to the QA column on the Sprint board.
• [x] After the CI has deployed the build, ask @Linda Setchell to do QA. Send a message asking for QA to be performed in the #nos-ios channel detailing the version (x.y.z) and build number and wait for her feedback. You can check the build number in [App Store Connect](https://appstoreconnect.apple.com/apps/1670125746/testflight/ios) or by looking at the git tags, because it is set dynamically in CI and isn’t committed to the repository. QA should be performed on the production version of the app (named Nos), not Nos Staging or Nos Dev.
• [x] Perform [After QA](https://www.notion.so/After-QA-6d16f4cd33164b9b8d54e204aa118d14?pvs=21).

After QA

If bugs were found in QA that were blockers:

• [ ] fix the bugs, opening PRs for them that target the appropriate release branch.
• [ ] merge the PRs into the release branch once they are approved. Each merge will trigger a new build of the production app. You can monitor its progress [here](https://github.com/planetary-social/nos/actions/workflows/testflight-deploy.yml).
• [ ] After all bugs are fixed and CI has finished deploying them ask @Linda Setchell to do QA again on the new build.

If no blockers were found, proceed with release:

• [x] Do some quick smoke testing and verify that data for the build is showing in [Posthog](https://us.posthog.com/project/56924/insights/KSXEmfTd) and [Sentry](https://sentry.nos.social/organizations/verse/releases/?environment=production&project=2&statsPeriod=24h). You can launch the build, force quit it, and launch again to trigger these libraries to send their data. This verifies that it wasn’t deployed with empty build secrets (especially if you did a manual deployment, but check it every time anyway; things could have gone wrong in CI).
• [x] Check out the appropriate release branch on your local machine.
• [x] Run git pull
• [x] Run fastlane stamp_release. This will apply the latest version header to the changelog and push changes to origin (and send a new build to TestFlight)
• [x] Merge the release branch into main.
• [x] Delete the release branch

git push -d origin release/x.y.z
git branch -d release/x.y.z

• [x] On main, bump the version number for the next build by running fastlane bump_patch or bump_minor. Commit changes (git commit -m '**[Bump marketing version to x.y.z+1'](https://github.com/planetary-social/nos/commit/f1bd2cde1515513b2941a9dda8e29378bf48c2cc)**) and push.
• [x] In the [TestFlight dashboard](https://appstoreconnect.apple.com/apps/1670125746/testflight/ios), update the testing notes to remove overly technical language.
• [x] In the [TestFlight dashboard](https://appstoreconnect.apple.com/apps/1670125746/testflight/ios), add the “Beta Public” and “Moar Beta Public” groups to the build. Leave the “notify testers” box checked.
• [x] Wait for Apple to process the build until the status in TestFlight is “✅ Testing”
• [x] Post the release notes from the [Nos.social](http://Nos.social) Nostr account