Firefox, and Mozilla technology in general, are under constant
development by the Mozilla Foundation. The Firefox source code is
also freely available for anyone to compile, so executable or
installable versions of Firefox could come from anywhere. Most such
distributions aren't widely known, though. This hack
explains what's out there, where to find it, and
what makes sense to try out.

Rebundled Firefox Versions

Some people take standard Firefox installers and rebundle the same
product up into a form that provides an alternate install process.
It's the same old Firefox, just packaged slightly
differently. Such things aren't full rebuilds.

Alternate Builds of Standard Firefox

There's an unending stream of changes being made to
the source code that Firefox derives from, and experimental builds
are being made constantly and automatically for several platforms.
There are many different Firefox builds, but they can be divided into
three rough categories:

Developer builds

These are based on Firefox source
code of no particular significance. Typically, these builds are
experimental and unstable. Examples include nightly
builds, trunk builds, and
debug builds.

Branch point builds

These are builds of special significance and are marked in the
source code repository with a CVS tag and a CVS branch tag. Such
builds are given a name. Examples include alphas
(1.8alpha2), betas (1.8beta3), release
candidates (Firefox 1.0 RC3), minorversions (Firefox 1.1), and major
version (Firefox 2.0). Such builds are usually built
optimized.

Branch patch builds

Once a branch point is made, no more features are added to the
branch, only bug fixes. Those few fixes will be lost to all other
builds unless extra steps are taken to copy them from the branch.
Often a branch has none of these fixes at all, as the developers are
already moving on to more important changes. Examples include minor
security releases (Mozilla 1.7.3).

In this system, CVS branches are rarely used for innovative
development of Firefox or Mozilla. The branches are used just to
quash bugs. Nearly all new work is done on the CVS
trunk, which is not a
branch. There is some confusion about this.
While Firefox was in early development, development was done on a
special branch (a long-lived branch) called
aviary. Now that Firefox has reached 1.0, that
long-lived branch is no longer required, and the trunk is being used
for most things again, including all new Firefox development.

Generally speaking, the developer builds carry small risks of
strange bugs and strange side effects that might confuse your
desktop. Don't use them on an important computer,
unless you know what you're doing. If
they're debug builds, as many are, they will
generally run more slowly than standard Firefox.

Developer builds don't always have full installers.
To proceed on Windows, first install standard Firefox. Next, rename
the folder that holds the Firefox install area. Unarchive the
downloaded build into a temporary folder. Rename the temporary folder
to the original install area folder's name. Start
the Firefox executable in that replacement folder. On Unix/Linux and
Macintosh, just unarchive the build into any folder and run.

Mozilla developers sometimes make experimental builds with special
features in place. They're examples of
custom builds.

Treasure-Hunting Custom Builds

To build Firefox from source code, an enthusiast needs four things in
place: a baseline, a target, a .mozconfig file [Hack #93], and source code. The
baseline is the set of tools used to build
Firefox; the target is the platform the new
Firefox is meant for; a .mozconfig file
specifies all the options that will apply to the build; and the
source code is some set of Firefox source files
from somewhere in CVS. Amidst all these factors, any number of subtly
different builds might be created.

The main motivation for such custom builds is to add back features
that are available in the source code but that
aren't in the standard install. Popular examples
iclude MNG image support; SVG support (with or without Cairo); Pango,
Xft, or Qt support on Linux; optimizations; and experiments with
alternate compilers.

All of these build alternatives are fairly harmless, but finding
someone willing to commit to fully maintaining their special build is
almost impossible. Such builds should be seen as wonderful
experiments, not as mainstream products—at least not until the
builders become more organized.