Plan publishing and updates

A release is an upgrade path from code you shipped before. Treat the artifact, metadata, signature, and update policy as one unit.

Build and test every supported operating system and architecture. Install over the previous version, launch from a clean account, create and export a note, restart, and uninstall.

Publish each artifact with its version, platform, architecture, and checksum. Keep old releases available long enough to diagnose regressions.

Electron Forge publishers upload artifacts; they do not automatically make every artifact safely updateable. Electron’s built-in updater supports macOS and Windows, while Linux distribution commonly follows the package manager or another platform-specific path.

Automatic updates need:

• immutable versioned artifacts and compatible update metadata
• HTTPS from a controlled update source
• signed applications, including the macOS signing prerequisite
• staged testing from the previous supported version
• a response plan for a bad release
• clear behavior when download, verification, or installation fails

Start with manual downloads if you are not ready to operate updates safely. Add automatic updates only after signed release artifacts and upgrade tests are routine.

Write a short release checklist now. Include versioning, tests, packaging, signing, malware scanning where applicable, upload, download verification, and announcement.

Add two update exercises. First, update from version 1.0.0 to 1.0.1 and confirm notes remain under the same application identity. Then make the update source unavailable and confirm the installed app still starts and preserves data.

Do not rely on “latest” as a rollback strategy. Once a broken update installs, you need a tested recovery release with a higher version or a documented manual recovery path.