Skip to main content

Release checklist

Use this checklist when preparing installer media for testers or a public DeepPhe release.

Before Building

  • Confirm the intended DeepPhe version.
  • Update the application version in DeepPhe-and-Launcher.install4j, or pass --release VERSION to build-all.sh.
  • Confirm the DeepPhe-Dist release tags and asset names in DeepPhe-and-Launcher.install4j.
  • If downloadable Windows payloads changed, update matching tags in sign-windows-assets.sh.
  • Confirm signing credentials are available only through environment variables, the macOS keychain, or the YubiKey.
  • Run npm run build in website/ if docs changed.

Build Installer Media

For a signed release build:

./build-all.sh

For a quick unsigned test build:

./build-all.sh --no-installer-signing --faster

The expected output is:

build/deepphe-installer/
├── DeepPhe.dmg
├── DeepPhe_windows.exe
├── DeepPhe_linux-x64.sh
├── output.txt
└── updates.xml

Sign Downloadable Windows Payloads

If the DeepPhe-Dist Windows payloads need signing, run:

./build-all.sh --sign

or:

./sign-windows-assets.sh

Smoke-test the signed .exe payloads on Windows before trusting them.

Publish Installer Media

Publish the installer media to DeepPhe-Dist:

./build-all.sh --publish

Use --publish-tag for a test or nonstandard tag.

Verify The Release

  • Confirm the GitHub release contains the 7.1 installer resources:
PlatformFileSHA-256Size
macOSDeepPhe-7.1.dmg7ab36501f824bc20605f4075c0bfb7cc5e0fa6481c632784b0225b550f7d0f6e141 MB
WindowsDeepPhe_windows-7.1.exea1f55ad0ad200aa3ff7882796d10f755e9075074a892473d06e995bb26953558134 MB
LinuxDeepPhe_linux-x64-7.1.sh53171da4f4d78565da4fabd6e8d5fdc297e588f580835271e01beda936958895136 MB
  • Download the media from the release, not from the local build directory.
  • Run the smoke-test matrix on macOS, Windows, and Linux.
  • Confirm install and uninstall behavior on each platform.
  • Confirm ~/DeepPheDocs is preserved when the uninstall checkbox is left unchecked.

After Release

  • Update user-facing links to the release if needed.
  • Deploy the docs site if the published documentation changed.
  • Keep generated media out of Git.