3.9 KiB
Releases
Conceptually, the release is straightforward:
-
We trigger a GitHub workflow that creates a (pre-)release with the build.
-
When ready, we make that release the latest.
-
The download links on our website, and existing apps already check the latest GitHub release and update automatically.
The complication comes from the fact that electron-builder's auto updater (the mechanism that we use for auto updates) doesn't work with monorepos. So we need to keep a separate repository just for holding the releases.
-
Source code lives here, in ente-io/ente.
-
Releases are done from ente-io/photos-desktop.
Nightly builds
Nightly builds of main
are published by a scheduled workflow automatically.
Each such workflow run will update the artifacts attached to the same
(pre-existing) pre-release.
If needed, this workflow can also be manually triggered:
gh workflow run desktop-release.yml --source=<branch>
Release checklist
-
Update source repo to set version
1.x.x
inpackage.json
and finalize the CHANGELOG. -
Merge PR then tag the merge commit on
main
in the source repo:git tag photosd-v1.x.x git push origin photosd-v1.x.x
-
In the release repo:
./.github/trigger-release.sh v1.x.x
This'll trigger the workflow and create a new pre-release. We can edit this to add the release notes, and convert it to a release.
Once it is marked as latest, the release goes live.
We are done at this point, and can now update the other pre-release that'll hold subsequent nightly builds.
-
Update
package.json
in the source repo to use version1.x.x-beta
, and merge these changes intomain
. -
In the release repo, delete the existing nightly pre-release, then:
git tag v1.x.x-beta git push origin v1.x.x-beta
-
Start a new run of the workflow (
gh workflow run desktop-release.yml
). -
Once the workflow creates the new 1.x.x-beta pre-release, edit its description to "Nightly builds".
Subsequent scheduled nightly workflows will keep updating this pre-release.
Ad-hoc builds
To create extra one-off pre-releases in addition to the nightly 1.x.x-beta
s,
-
In your branch in the source repository, set the version in
package.json
to something different, say1.x.x-foo
. -
Create a new pre-release in the release repo with title
1.x.x-foo
. In the tag input enterv1.x.x-foo
and select the option to "Create a new tag on publish". -
Trigger the workflow in the release repo:
gh workflow run desktop-release.yml --source=my-branch
Details
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 and signs the macOS DMG (For this it uses credentials provided via GitHub secrets).
To rollout the build, we need to publish the draft release. Thereafter, everything is automated:
-
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 yet). -
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.