Skip to content
This repository has been archived by the owner on Jan 6, 2022. It is now read-only.

How releases work

Julian Gruber edited this page May 25, 2017 · 6 revisions

Our release process is 99% automated, via Travis and electron-builder. Every time you push a new passing commit to the master branch, Travis will build it in the after_success phase. On success thereof, it will check dat-desktop's releases and see if there's an unpublished release matching the version number currently set in the /package.json. If there is, it will upload the binaries (.dmg, .zip and .AppImage) to it.

This publishing flow is called onTagOrDraft and is the default flow of publishing assets with electron-builder, as also advised in their wiki. This flow has the advantage that you get prerelease binaries for every commit - that you can share with your team at will - and to publish the release you simply hit the publish button on the release page on GitHub. It's that easy!

We run OSX and Linux on Travis, giving us the following assets:

  • .dmg: OSX main release
  • .zip: OSX release used by the auto updater
  • .AppImage: *nix compatible release

The build is configured via the "build" property in our /package.json, where you can change settings like how the DMG should be built and what protocols the app listens to.

Step by step

  1. Create a new draft prerelease for the next version. New #master builds will be uploaded to it
  2. Once ready, add release notes and hit publish, unticking the prerelease checkbox
  3. Create a new draft prerelease for the next version. Rinse and repeat.

Signing

Just a quick note about signing: The properly sign a release for OSX, you need to have an Apple Developer Account. There currently is @juliangruber's account information stored encrypted as a secret environment variable on Travis, which allows us to build. In case this license runs out, follow this manual on how to update it to a new account.

Clone this wiki locally