github-personal/firezone
1
0
Fork 0
mirror of https://github.com/outbackdingo/firezone.git synced 2026-01-27 18:18:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update release playbook (#5863)

Browse Source 
Update MAINTAINERS.md with most recent release playbook.

```[tasklist]
### Tasks
- [x] Merge `publish_release.md` into `MAINTAINERS.md`
- [ ] Merge PR
```

---------

Co-authored-by: Not Applicable <ReactorScram@users.noreply.github.com>
This commit is contained in:
Jamil
2024-07-12 14:19:36 -07:00
committed by GitHub
parent a8ece49d9e
commit 478229e605
1 changed files with 25 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/MAINTAINERS.md
View File

@@ -7,37 +7,39 @@ Table of Contents:
- [Releasing](#releasing)
- [Publishing Clients](#publishing-clients)
- [Apple Client](#apple-client)
- [Apple Client](#apple-client)
- [Breaking API Changes](#breaking-api-changes)
## Releasing
**Note**: The version gets set from the Makefile
**Note**: The version for all published components is set from [scripts/Makefile](../scripts/Makefile).
- Go to Actions tab in GH
### App Store clients (Apple/Android)
- For apple the workflow is `Swift`
- For Android the workflow is `Kotlin`
1. Go to Actions tab in GH and run the `Kotlin` or `Swift` workflow appropriately
1. This will push new release builds to Firebase or App Store Connect and pushed out Firebase App Distribution or TestFlight respectively.
1. Test this build manually a bit since we have no automated client tests yet
1. To submit for review:
- For Apple, do this through AppStore connect. Details are [below](#apple-client).
- Android, download the AAB from Firebase App Distribution, create a new release in Google Play Console, and upload the AAB.
- Click the edit button on the Draft 1.0.0 release
- Give the release a name (manually - right now we're using
`1.0.0-pre.<num-here>`)
- Create a new tag as well with the same name as the release (click
`create new tag`)
- Double check that the body text of the release is what is expected
- **IMPORTANT**: Scroll to the bottom and check the `Set as latest release` and
uncheck `Set as pre-release`
- Click `Publish Release`
- The `Publish` workflow is now run Note: This will deploy to production and the
following will happen
- All logged in users on the portal will be logged out, but the clients will
not be logged out
- All the websockets will be disconnected and should automatically reconnect
### GitHub-released components (Linux, Windows, and Gateway)
## Publish Clients
Given that `main` is tested:
### Android Client
1. Go to the draft release of the component you want to publish
1. Double-check that the assets attached are from a recent CI and include the
correct changes.
1. Publish the release. Tags and release name should be auto generated. This will trigger pushing Docker images to `ghcr.io`.
1. Open a PR and making the following changes.
1. Update [scripts/Makefile](../scripts/Makefile) with the new version number(s). Run `make -f scripts/Makefile version` to update the version in the Makefile.
1. Update the Changelog (e.g. `../website/src/components/Changelog/GUI.tsx`) with the new version number(s) and release notes.
1. Update the known issues in `website/src/app/kb/user-guides/*`
1. When the PR merges, the website will now redirect to the new version(s).
-
This results in a gap where GitHub knows about the release but nobody else does.
This is okay because we can undo the GitHub release, and it prevents any queued PRs
from landing in the release while you execute this process.
### Apple Client
@@ -72,4 +74,4 @@ Table of Contents:
## Breaking API changes
We should notify customers 2 weeks in advance for any API-breaking changes.
We should notify customers **2 weeks in advance** for any API-breaking changes.