3.9 KiB
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.
-
Create a new branch (can be named anything). On this branch, include your changes.
-
Mention the changes in
CHANGELOG.md
. -
Changing the
version
inpackage.json
to1.x.x
. -
Commit and push to remote
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,
-
Open a PR for the branch that we're working on (where the above tag was pushed from) to get it merged into main.
-
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 tov4.0.2-next.0
. Each pre-release will modify thenext.0
part. Finally, at the time of the next release, this'll becomev4.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.