How Channels Work
Users who receive “beta” versions will also get “latest” versions. However, users who don’t opt into “beta” will only receive “latest” releases.Channel Hierarchy
There are three channels, ordered by stability:- latest - Your application is stable and this is the default channel (example:
1.3.2) - beta - Your application works, but may have some bugs (example:
1.3.2-beta) - alpha - Your application is not stable and in active development (example:
1.3.2-alpha)
Version Distribution
Depending on the channel a user is subscribed to, they will receive different versions:| User Channel | Receives Versions |
|---|---|
latest or none | Only “latest” versions |
beta | ”beta” and “latest” versions |
alpha | ”alpha”, “beta”, and “latest” versions |
Configuration
Electron Builder Configuration
By default (without using channels), all application releases use the “latest” channel. To enable channels, add this to yourpackage.json:
package.json
allowDowngrade is automatically set to true when generateUpdatesFilesForAllChannels = true, so you don’t need to set it manually.Setting the Channel
All you have to do to release using channels is to define the channel in the version tag of thepackage.json:
- Add
-betafor beta releases - Add
-alphafor alpha releases - Nothing for “latest” releases
Application Configuration
In your application, define which channel the user will receive updates from:See the channel property documentation for more details.
Usage Example
Scenario: Releasing a Beta Version
Imagine your application is stable and in version1.0.1.
Step 1: Create a Beta Release
To release a beta for the new 1.1.0 version, update the package.json version:
package.json
1.1.0-beta:
-beta label:
package.json
1.1.0.
Advanced Configuration
Setting Channel Dynamically
You can allow users to switch channels within your application:Prerelease Handling
TheallowPrerelease property automatically detects if your application version contains prerelease components:
Channel Best Practices
Use semantic versioning - Follow semver conventions for version numbers
Test in beta first - Always test new features in beta before releasing to stable
Clear upgrade path - Ensure beta users can always upgrade to stable
Document channel purpose - Make it clear to users what each channel means
Monitor beta feedback - Use beta channel to gather feedback before stable release
Version Naming Conventions
Follow these conventions for clarity:| Version Type | Format | Example |
|---|---|---|
| Stable | MAJOR.MINOR.PATCH | 1.2.3 |
| Beta | MAJOR.MINOR.PATCH-beta.BUILD | 1.2.3-beta.1 |
| Alpha | MAJOR.MINOR.PATCH-alpha.BUILD | 1.2.3-alpha.1 |
| Release Candidate | MAJOR.MINOR.PATCH-rc.BUILD | 1.2.3-rc.1 |
Example Workflow
Complete Release Cycle
Configuration for Each Stage
package.json (Alpha)
package.json (Beta)
package.json (Stable)
Downgrading Between Channels
WhenallowDowngrade is set to true (which happens automatically with generateUpdatesFilesForAllChannels), users can move from a beta channel back to stable:
Testing Channels
To test channel functionality locally:- Build and install version
1.0.0(stable) - Build version
1.1.0-betaand publish to your update server - In your installed app, switch to beta channel:
- Check for updates - should detect
1.1.0-beta - Switch back to stable channel:
- Check for updates - should stay on or offer
1.0.0(ifallowDowngradeis true)
Related Resources
Auto-Update Setup
Learn how to set up auto-updates in your application
Testing Updates
Test auto-updates locally with Minio