|
|
@@ -0,0 +1,92 @@
|
|
|
+## Releases
|
|
|
+
|
|
|
+> [!NOTE]
|
|
|
+>
|
|
|
+> TODO(MR): This document needs to be audited and changed as we do the first
|
|
|
+> release from this new monorepo.
|
|
|
+
|
|
|
+The Github Action that builds the desktop binaries is triggered by pushing a tag
|
|
|
+matching the pattern `photos-desktop-v1.2.3`. This value should match the
|
|
|
+version in `package.json`.
|
|
|
+
|
|
|
+So the process for doing a release would be.
|
|
|
+
|
|
|
+1. Create a new branch (can be named anything). On this branch, include your
|
|
|
+ changes.
|
|
|
+
|
|
|
+2. Mention the changes in `CHANGELOG.md`.
|
|
|
+
|
|
|
+3. Changing the `version` in `package.json` to `1.x.x`.
|
|
|
+
|
|
|
+4. Commit and push to remote
|
|
|
+
|
|
|
+ ```sh
|
|
|
+ git add package.json && git commit -m 'Release v1.x.x'
|
|
|
+ git tag v1.x.x
|
|
|
+ git push && git push --tags
|
|
|
+ ```
|
|
|
+
|
|
|
+This by itself will already trigger a new release. The GitHub action will create
|
|
|
+a new draft release that can then be used as descibed below.
|
|
|
+
|
|
|
+To wrap up, we also need to merge back these changes into main. So for that,
|
|
|
+
|
|
|
+5. Open a PR for the branch that we're working on (where the above tag was
|
|
|
+ pushed from) to get it merged into main.
|
|
|
+
|
|
|
+6. In this PR, also increase the version number for the next release train. That
|
|
|
+ is, supposed we just released `v4.0.1`. Then we'll change the version number
|
|
|
+ in main to `v4.0.2-next.0`. Each pre-release will modify the `next.0` part.
|
|
|
+ Finally, at the time of the next release, this'll become `v4.0.2`.
|
|
|
+
|
|
|
+The GitHub Action runs on Windows, Linux and macOS. It produces the artifacts
|
|
|
+defined in the `build` value in `package.json`.
|
|
|
+
|
|
|
+* Windows - An NSIS installer.
|
|
|
+* Linux - An AppImage, and 3 other packages (`.rpm`, `.deb`, `.pacman`)
|
|
|
+* macOS - A universal DMG
|
|
|
+
|
|
|
+Additionally, the GitHub action notarizes the macOS DMG. For this it needs
|
|
|
+credentials provided via GitHub secrets.
|
|
|
+
|
|
|
+During the build the Sentry webpack plugin checks to see if SENTRY_AUTH_TOKEN is
|
|
|
+defined. If so, it uploads the sourcemaps for the renderer process to Sentry
|
|
|
+(For our GitHub action, the SENTRY_AUTH_TOKEN is defined as a GitHub secret).
|
|
|
+
|
|
|
+The sourcemaps for the main (node) process are currently not sent to Sentry
|
|
|
+(this works fine in practice since the node process files are not minified, we
|
|
|
+only run `tsc`).
|
|
|
+
|
|
|
+Once the build is done, a draft release with all these artifacts attached is
|
|
|
+created. The build is idempotent, so if something goes wrong and we need to
|
|
|
+re-run the GitHub action, just delete the draft release (if it got created) and
|
|
|
+start a new run by pushing a new tag (if some code changes are required).
|
|
|
+
|
|
|
+If no code changes are required, say the build failed for some transient network
|
|
|
+or sentry issue, we can even be re-run by the build by going to Github Action
|
|
|
+age and rerun from there. This will re-trigger for the same tag.
|
|
|
+
|
|
|
+If everything goes well, we'll have a release on GitHub, and the corresponding
|
|
|
+source maps for the renderer process uploaded to Sentry. There isn't anything
|
|
|
+else to do:
|
|
|
+
|
|
|
+* The website automatically redirects to the latest release on GitHub when
|
|
|
+ people try to download.
|
|
|
+
|
|
|
+* The file formats with support auto update (Windows `exe`, the Linux AppImage
|
|
|
+ and the macOS DMG) also check the latest GitHub release automatically to
|
|
|
+ download and apply the update (the rest of the formats don't support auto
|
|
|
+ updates).
|
|
|
+
|
|
|
+* We're not putting the desktop app in other stores currently. It is available
|
|
|
+ as a `brew cask`, but we only had to open a PR to add the initial formula, now
|
|
|
+ their maintainers automatically bump the SHA, version number and the (derived
|
|
|
+ from the version) URL in the formula when their tools notice a new release on
|
|
|
+ our GitHub.
|
|
|
+
|
|
|
+We can also publish the draft releases by checking the "pre-release" option.
|
|
|
+Such releases don't cause any of the channels (our website, or the desktop app
|
|
|
+auto updater, or brew) to be notified, instead these are useful for giving links
|
|
|
+to pre-release builds to customers. Generally, in the version number for these
|
|
|
+we'll add a label to the version, e.g. the "beta.x" in `1.x.x-beta.x`. This
|
|
|
+should be done both in `package.json`, and what we tag the commit with.
|
Manav Rathi