Release Engineering

Pale Moon (and other applications built from the Unified XUL Platform Release train) utilize a four week release cycle. This is mainly due to Mozilla's similar move from a six to eight week cycle to releasing a new Firefox version every four weeks. Since we retain some historical similarity with our wayward sibling, both Application and Platform wise, we MUST take care to evaluate any Mozilla security fixes included in their releases.

The Release Cycle

Pale Moon will primarily be alternating between the type of release every four weeks with a Major/Feature release and a Minor/Security release. However, real world factors in tangible development may alter the intended cycle. Be sure to check this page or announcements made for such changes.

Version numbers and release types

The current Pale Moon version scheme is: [Milestone].[Major/Feature].[Minor/Security] with a fourth version point being reserved for [Out-of-band] releases. Each of these version points corresponds with a type of release for Pale Moon.

Release Type	Description
Milestone	A significant release that may include an abundance of new features and backward-incompatible changes.
Major/Feature	A release which includes new and updated features with or without minor backward-incompatible changes.
Minor/Security	A release with minor changes, bug fixes, and applicable security patches.
Out-of-band	An unscheduled release that resolves critical items on an ad-hoc basis.

NOTE: All release types MAY and often DO contain applicable security patches. For your safety it is recommend that you always stay up to date.

While we identify all UXP stable releases by date and the above types, we also still maintain an internal version number. This "mozilla milestone" version is not currently hard-defined according to any current scheme and should NOT be relied on for anything.

Current planned release schedule for Pale Moon

The advantage or disadvantage (depending on your point of view) to a set calendar based cycle is that, in general, our releases are predictable by specific calendar days. As such, we have outlined the anticipated release schedule and it will be kept updated for any changes.

Each date is offset from Mozilla's release day by one week to allow requesting of security access and evaluation of any known Mozilla vulnerabilities. This also gives us the time to test and stabilize the codebase for release.

Pale Moon Version	Closed tree	Intended Release Date	Type of Release
v33.2.1	2024-07-09	2024-07-15	Minor/Security Release
v33.3.0	2024-08-06	2024-08-13	Major/Feature release
v33.3.1	2024-09-03	2024-09-10	Minor/Security Release
v33.4.0	2024-10-01	2024-10-08	Major/Feature release
v33.4.1	2024-10-29	2024-11-05	Minor/Security Release
v33.5.0	2024-11-26	2024-12-03	Major/Feature release

Previous releases of Pale Moon and the Unified XUL Platform

Please refer to the Pale Moon release notes (or archived ones for older releases) and tagged UXP commits for previous releases.

The Release Workflow

Our release engineering workflow happens over the course of one week starting with Firefox Release Day which tends to always be a Tuesday and will run through the week to the following Tuesday which is our release day as outlined above.

• Tuesday - Firefox Release Day
  • The master branches will be placed under a "Closed Tree" type of condition where no high-risk patches and feature merges will be permitted until after merge day.
  • Security Access will be requested on all known Mozilla vulnerabilities described on the Mozilla Foundation Security Advisory.
• Tuesday through Friday - Security Updates
  • Each known Mozilla security vulnerability will be evaluated and patched, if applicable.
• Friday - Release Branch Preparations (Merge Day)
  • For Major Releases: The master branches will be merged to the release branches.
  • For Security Releases: The security patches and any minor patches will be cherry-picked to the release branches.
  • Application Release Notes and UXP Change Log will be drafted.
• Friday through Monday - Build and Test Release Candidates
  • Build signed binaries for various target operating systems and make them available for final acceptance tests.
  • Test built binaries for any show-stoppers. Implement spot-fixes or back-out problematic code changes that are too big to tackle on short notice. Building new binaries (RC2, 3, etc.) as-needed.
• Monday - Finalize Releases
  • Distribute final binaries to release mirrors.
  • Signal external mirrors.
  • Write final Application Release Notes.
• Tuesday - Our Release Day
  • Put web pages live, enable new downloads.
  • Publish announcements on forum and to any applicable social media.