Mozilla and Firefox use nightly builds and smoketests to ensure that the code is always working well enough for developers to test new code.
Benefits of using nightly builds:
Downsides of using nightly builds:
See the Firefox 2.0 Roadmap and Firefox 2.0 PRD for information about the upcoming 1.1, 1.5, and 2.0 releases.
This answer was updated December 4, 2004.
The trunk is where most Mozilla development happens. Because it is under constant development, there are often regressions. Before each release, a branch is created from the trunk. This allows heavy development to continue on the trunk while the branch takes fewer changes (mostly changes that improve stability and fix regressions). As a release nears, its branch takes fewer patches, and those patches are checked carefully to ensure they do not decrease stability.
Some branches, such as the Aviary branch that produced Firefox 1.0, exist for months and take large patches. This is rare.
When a branch is active, there are usually nightly builds available for both the trunk and the branch.
WFM stands for "Works for me" and means "I don't see this bug at all" or "I don't see this bug any more". (The WORKSFORME resolution in Bugzilla has the added meaning that nobody knows what checkin fixed the bug; if the checkin is known, the bug is marked as FIXED instead.)
Some people also use "WFM" to describe a build, meaning that they haven't noticed any major problems with a new build.
MSVC-specific flags:
There are more MSVC compiler-optimization flags (e.g. GL, GA, and GF) but I don't mention them when I link to builds.
Note that which version of MSVC is used can also influence speed.
Most of the time, doing one of the following will make the bug go away:
If none of those steps makes the problem go away, search Bugzilla to see if anyone has encountered the bug and whether they have found a workaround. You can also check the Firefox : Issues in the Mozillazine Knowledge Base, which lists common issues. The KB is especially useful compared to Bugzilla for problems that have multiple causes, such as Firefox won't start up and Firefox won't connect to any sites.
If you can't find your bug in Bugzilla, file a new bug report. It is a good idea to mention what you have tried, for example: "I tried reinstalling Firefox into an empty directory, disabling all extensions, and using a new profile, but none of those made the problem go away." If the bug is a crash, see the Talkback FAQ for how to identify and report the crash.
Only official milestone builds and official nightly builds have the new icons and About dialog artwork. Unofficial builds that are distributed should use the default "unofficial" artwork, which is a globe without a Fox, or supply their own artwork.
The Burning Edge is in Pacific Time (GMT-8, GMT-7 from April to October). Build dates (and, for official builds, hours) are also in Pacific Time. The primary mirrors that make up the ftp.mozilla.org pool are in various time zones, so be wary of any time you see on a ftp server other than in the name of a folder.
Checkin log for Firefox and Bonsai Bugs for Firefox (70%), Bonsai Bugs for Mozilla (only 10% because I omit most Gecko changes), bugmail from bugs I reported or am cc'ed on (10%), Mozillazine Builds Forum (10%).
List of newly reported bugs (30%), list of regressions with at least one vote (30%), my own use and testing (20%), Mozillazine Builds Forum and comments on The Burning Edge (20%).
The main factors are my judgment of severity, my estimate of what percent of nightly users are affected, how quickly the regression was recognized, and the number of votes divided by the age of the bug.