Skip to content

chore: Enable alpha releases#3180

Merged
jeanfbrito merged 15 commits intodevfrom
alpha-releases
Jan 23, 2026
Merged

chore: Enable alpha releases#3180
jeanfbrito merged 15 commits intodevfrom
alpha-releases

Conversation

@jeanfbrito
Copy link
Copy Markdown
Member

@jeanfbrito jeanfbrito commented Jan 23, 2026

Enables proper alpha and beta release channels for QA and customer testing. This PR adds the prerelease flag to GitHub releases for alpha/beta versions and prevents the auto-updater from offering downgrades as "updates" to users running development builds.

Root Cause Analysis

The Problem

Two issues prevented effective alpha channel usage:

  1. GitHub releases not marked as prerelease: When creating releases with tags like 4.12.0-alpha.1, the GitHub release was not marked as "Pre-release", causing it to appear as the "Latest Release" to all visitors.

  2. False update notifications: Users running PR/development builds (e.g., 4.11.0) were being offered "updates" to older stable versions (e.g., 4.10.0). This occurred because generateUpdatesFilesForAllChannels: true in electron-builder automatically enables allowDowngrade: true.

Five Whys

Issue 1: Alpha releases showing as "Latest Release"

  1. Why did alpha releases appear as latest? → GitHub wasn't told they were prereleases
  2. Why wasn't GitHub told? → The prerelease flag wasn't set in the release API call
  3. Why wasn't it set?getTaggedRelease() didn't check for prerelease version components

Issue 2: Downgrade offered as update

  1. Why was 4.10.0 offered as update to 4.11.0? → electron-updater's update-available event fired
  2. Why did it fire for an older version?allowDowngrade was enabled
  3. Why was allowDowngrade enabled?generateUpdatesFilesForAllChannels: true automatically enables it
  4. Why is that setting enabled? → Required for multi-channel (alpha/beta/stable) support

Root Cause

  1. Missing prerelease: true flag in GitHub release creation for versions with prerelease components
  2. No version comparison before showing update notifications to users

The Fix

Approach

For prerelease flag: Detect prerelease versions using semver's prerelease array and pass the flag to GitHub's release API.

For downgrade prevention: Compare versions using semver before dispatching UPDATES_NEW_VERSION_AVAILABLE. If the "update" version is not greater than current, silently ignore it.

Implementation

1. GitHub Release Prerelease Flag

workspaces/desktop-release-action/src/github.ts:112-148

export const getTaggedRelease = async (version: SemVer, commitSha: string) => {
  const body = await getChangelog();
  const isPrerelease = version.prerelease.length > 0;  // NEW

  // ... in both PATCH and POST requests:
  prerelease: isPrerelease,  // NEW

The semver library's SemVer type has a prerelease array that contains components like ['alpha', 1] for version 4.12.0-alpha.1. An empty array means stable release.

2. Version Comparison Before Update Notification

src/updates/main.ts:249-263

autoUpdater.addListener('update-available', ({ version }) => {
  // ... existing skip logic ...

  // Prevent showing "updates" that are actually downgrades
  const currentVersion = app.getVersion();
  try {
    if (!semverGt(version as string, currentVersion)) {
      dispatch({ type: UPDATES_NEW_VERSION_NOT_AVAILABLE });
      return;
    }
  } catch {
    // If version comparison fails, proceed with the update
  }

  dispatch({ type: UPDATES_NEW_VERSION_AVAILABLE, payload: version });
});

Files Changed

File Change
workspaces/desktop-release-action/src/github.ts Added isPrerelease detection and prerelease flag to release API calls
workspaces/desktop-release-action/dist/index.js Rebuilt action bundle
src/updates/main.ts Added semver import and version comparison logic
docs/alpha-release-process.md New documentation for creating and using alpha releases

Architecture

Release Channel Flow

Version Tag                    electron-builder              GitHub Release
─────────────────────────────────────────────────────────────────────────────
4.12.0          ──────────►   latest.yml        ──────────►  Latest Release
4.12.0-beta.1   ──────────►   beta.yml          ──────────►  Pre-release ✓
4.12.0-alpha.1  ──────────►   alpha.yml         ──────────►  Pre-release ✓

Update Check Flow

User App                    electron-updater                 Action
─────────────────────────────────────────────────────────────────────────────
channel=latest  ──────────►  checks latest.yml  ──────────►  Only stable
channel=beta    ──────────►  checks beta.yml    ──────────►  Beta + stable
channel=alpha   ──────────►  checks alpha.yml   ──────────►  Alpha + beta + stable

Downgrade Prevention Flow

                    update-available event
                            │
                            ▼
                ┌───────────────────────┐
                │ Is offered version >  │
                │ current version?      │
                └───────────────────────┘
                     │           │
                    YES          NO
                     │           │
                     ▼           ▼
              Show update    Silently ignore
              dialog         (no notification)

Verification

Testing the Prerelease Flag

After merging, create an alpha release:

# Update package.json to "4.12.0-alpha.1"
git tag 4.12.0-alpha.1
git push origin 4.12.0-alpha.1

Verify:

  1. GitHub release shows "Pre-release" badge
  2. Release does NOT show as "Latest Release"
  3. alpha.yml exists in release assets

Testing Downgrade Prevention

yarn build
yarn start
  1. Run a development build with version higher than published stable
  2. Open About dialog → Check for Updates
  3. Should show "No updates available" (not offer downgrade)

Testing Alpha Channel Opt-in

  1. Enable Developer Mode in Settings
  2. Open About dialog
  3. Select "Alpha (Experimental)" from dropdown
  4. Click "Check for Updates"
  5. Alpha release should be offered

Considerations

What This Doesn't Change

  • Existing stable release flow unchanged
  • Users on stable channel unaffected
  • No changes to build process or artifacts

Potential Risks

  • Version parsing edge cases: If semver parsing fails, update proceeds (fail-safe)
  • Channel selector still behind dev mode: Intentional - prevents accidental alpha opt-in

References

Summary by CodeRabbit

  • New Features

    • Added ARM64 support for Windows builds and tooling to create & publish prerelease tags/releases.
  • Bug Fixes

    • Update checks now only notify users when a newer app version is available.
  • Documentation

    • Added comprehensive Alpha release process and troubleshooting guidance.
  • Chores

    • Bumped package to an alpha version, adjusted release metadata to honor prereleases, updated CI branch triggers, and expanded lint ignore paths.

✏️ Tip: You can customize this high-level summary in your review settings.

…ge configurations

- Updated Electron dependency from version 39.2.5 to 40.0.0 in package.json and yarn.lock.
- Bumped Node.js version requirements in package.json and devEngines to >=24.11.1.
- Revised README.md to reflect new supported platforms and minimum version requirements.
- Removed deprecated tests related to ELECTRON_OZONE_PLATFORM_HINT in app.main.spec.ts.
- Enhanced documentation for development prerequisites and troubleshooting sections.
- Updated the bundle version in electron-builder.json from 26010 to 26011.
- Incremented the application version in package.json from 4.11.1 to 4.12.0.
…formats

- Revised the supported platforms section to include additional architectures and installation formats for Windows, macOS, and Linux.
- Updated download links for Microsoft Store and Mac App Store, ensuring accurate access to application sources.
- Updated the formatting of download links for Microsoft Store, Mac App Store, and Snap Store to improve visual presentation and accessibility.
- Changed from a div-based layout to a paragraph-based layout with adjusted image sizes for better responsiveness.
- Introduced a new document detailing the alpha release process for the Rocket.Chat Desktop app, including channel definitions, versioning guidelines, and steps for creating and publishing alpha releases.
- Included instructions for users to opt into the alpha channel and troubleshooting tips for common issues.
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Jan 23, 2026

Walkthrough

Adds alpha release documentation and a tagging CLI; bumps package.json to an alpha, increments electron bundleVersion, adds Windows arm64 targets, gates update-available dispatch with a semver check, sets prerelease on GitHub Releases, and standardizes CI branch name from "develop" → "dev".

Changes

Cohort / File(s) Change Summary
Documentation
docs/alpha-release-process.md
New file describing Alpha release channel, publish steps, opt-in methods, versioning rules, and troubleshooting.
Release tagging script & package metadata
scripts/release-tag.ts, package.json
New interactive release-tag.ts added; package.json version bumped to 4.12.0-alpha.1 and release:tag npm script added.
Build configuration
electron-builder.json
bundleVersion incremented; Windows targets (nsis, msi, zip) now include arm64 architecture.
Update flow
src/updates/main.ts
Import semver.gt and verify new update version is greater before dispatching UPDATES_NEW_VERSION_AVAILABLE; otherwise dispatch UPDATES_NEW_VERSION_NOT_AVAILABLE.
GitHub release automation
workspaces/desktop-release-action/src/github.ts
Compute prerelease from version.prerelease and set prerelease flag when creating/updating GitHub Releases.
Release action control & workflows
workspaces/desktop-release-action/src/index.ts, .github/workflows/* (build-release.yml, powershell-lint.yml, pull-request-build.yml, validate-pr.yml)
Standardized development branch name from developdev in action logic and workflow triggers; added jsign path check in PR build workflow.
Tooling / Lint
.eslintignore
Added /scripts to files ignored by ESLint.

Sequence Diagram(s)

mermaid
sequenceDiagram
participant User
participant CLI as release-tag.ts
participant LocalGit as Local Git
participant GitHub as GitHub (Releases & Actions)
User->>CLI: run npm run release:tag
CLI->>LocalGit: fetch tags, check existing tags, compute channel latest
CLI->>User: prompt for confirmation (show plan)
User->>CLI: confirm
CLI->>LocalGit: create tag, push tag to origin
LocalGit->>GitHub: pushed tag triggers Actions
CLI->>GitHub: (optional) open Releases URL
GitHub-->>CLI: CI status / release page

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Poem

🐰 I hopped a tag into the night,
alpha badges shining bright,
arm64 boots, a tiny cheer,
dev renamed and CI near—
carrots for the build, hop tight! 🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'chore: Enable alpha releases' directly summarizes the main objective of the PR, which is to implement proper alpha and beta release channels with supporting infrastructure changes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch alpha-releases

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
package.json (1)

41-41: Release script only targets x64 architecture, missing ia32.

The release script specifies --x64 only, which restricts the build to x64 architecture. However, the electron-builder.json configuration defines Windows support for both x64 and ia32 architectures. To match the configured architectures, either remove the --x64 flag to use all configured architectures, or explicitly specify both: --x64 --ia32.

Note: The project's electron-builder configuration does not include arm64 support for Windows.

🤖 Fix all issues with AI agents
In `@package.json`:
- Around line 145-148: The package.json currently pins engines.node and
devEngines.node to ">=24.11.1", which is overly restrictive; change both "node"
entries (the engines.node and devEngines.node keys) to a broader minimum such as
">=20.0.0" (or a semver expression like ">=20 || >=22 || >=24") so contributors
on older LTS releases can run and develop; update both keys to the chosen
relaxed range and ensure package metadata remains consistent.
- Line 116: Update the electron-builder dependency to 26.5.0 or newer in
package.json (replace the current "electron-builder" version) and update the
Windows targets in electron-builder.json so each win.target entry ("nsis",
"msi", "zip") includes "arm64" in its arch array alongside "x64" and "ia32";
modify the dependency version and the arch arrays for the win targets to ensure
Electron 40 compatibility and include arm64 builds.
🧹 Nitpick comments (4)
electron-builder.json (1)

58-72: Missing arm64 architecture for Windows builds.

Per coding guidelines, Windows build commands should include all architectures: x64, ia32, and arm64. Currently only x64 and ia32 are configured for nsis, msi, and zip targets.

♻️ Proposed fix to add arm64 architecture
   "win": {
     "target": [
       {
         "target": "nsis",
-        "arch": ["x64", "ia32"]
+        "arch": ["x64", "ia32", "arm64"]
       },
       {
         "target": "msi",
-        "arch": ["x64", "ia32"]
+        "arch": ["x64", "ia32", "arm64"]
       },
       {
         "target": "zip",
-        "arch": ["x64", "ia32"]
+        "arch": ["x64", "ia32", "arm64"]
       }
     ],

Based on coding guidelines: "When modifying Windows build commands, ensure all architectures are included: x64, ia32, and arm64 with electron-builder".

src/updates/main.ts (1)

252-263: Good defensive check against downgrades.

The version guard correctly prevents showing "updates" that would be downgrades. The fallback in the catch block (proceeding with the update if comparison fails) is a safe choice.

Consider adding minimal logging in the catch block to aid debugging when version parsing fails:

♻️ Optional: Add debug logging for parse failures
     try {
       if (!semverGt(version as string, currentVersion)) {
         dispatch({ type: UPDATES_NEW_VERSION_NOT_AVAILABLE });
         return;
       }
-    } catch {
+    } catch (error) {
       // If version comparison fails, proceed with the update
+      console.log('Version comparison failed, proceeding with update', JSON.stringify({
+        version,
+        currentVersion,
+        error: error instanceof Error ? error.message : String(error),
+      }));
     }
package.json (1)

37-37: Windows build script missing explicit architecture flags.

Per coding guidelines, Windows build commands should include all architectures: x64, ia32, and arm64 with electron-builder. The current build-win script doesn't specify architectures explicitly.

Suggested fix
-    "build-win": "yarn build && yarn electron-builder --publish never --win",
+    "build-win": "yarn build && yarn electron-builder --publish never --win --x64 --ia32 --arm64",

Based on learnings, when modifying Windows build commands, ensure all architectures are included.

README.md (1)

256-258: Consider varying sentence structure for readability.

Three successive sentences begin with "When", which can feel repetitive. A minor rewording could improve flow.

Suggested improvement
-When `isTrayIconEnabled` is enabled, the app will be hidden on close.
-When `isMinimizeOnCloseEnabled` is enabled, the app will be minimized on close.
-When both are disabled, the app will quit on close.
+If `isTrayIconEnabled` is enabled, the app will be hidden on close.
+If `isMinimizeOnCloseEnabled` is enabled, the app will be minimized on close.
+With both disabled, the app will quit on close.

@jeanfbrito jeanfbrito changed the title Alpha releases chore: Enable alpha releases Jan 23, 2026
@jeanfbrito jeanfbrito changed the base branch from master to dev January 23, 2026 21:37
- Added 'arm64' architecture support to the build targets in electron-builder.json for NSIS, MSI, and ZIP formats.
- Lowered the minimum Node.js version requirement in package.json from >=24.11.1 to >=20.0.0 for better compatibility.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@package.json`:
- Around line 145-149: Update the package.json engine entries to require Node
>=22.0.0 by changing the "engines.node" value and the "devEngines.node" value
from ">=20.0.0" to ">=22.0.0"; locate the "engines" and "devEngines" sections
(symbols "engines.node" and "devEngines.node") and modify both entries
consistently so tooling and contributors use Node 22+.
♻️ Duplicate comments (1)
package.json (1)

116-116: Verify tooling compatibility with Electron 40.0.0.
Please confirm the current electron-builder version supports Electron 40.0.0, and upgrade if required.

electron-builder compatibility with Electron 40.0.0 and latest electron-builder release