On 04/12/2016 12:08 PM, The Wanderer wrote
The Firefox development process follows a type of cascading release:
http://www.askvg.com/mozilla-updates-firefox-update-channels-nightly-aurora-beta-and-release/
There are nightly builds, which are compiled every night from the public
source tree (assuming it actually builds at the moment), and made
available for developer use. These are bleeding-edge, potentially
unstable and buggy code.
There's the 'Aurora' release channel, which is the next stage of
stability after nightly builds. It's more or less the "experimental
release" niche, the first step towards designating something as a
release; think of it as comparable to an alpha release. After the old
'Aurora' becomes the new 'Beta', a version of the latest nightly code
becomes the new Aurora. Not every new patch gets into Aurora - only
patches which the developers agree are important for the coming release.
There's the 'Beta' release channel, which is the next stage of stability
after Aurora. After the old 'Beta' becomes the new 'Release' version,
the old Aurora becomes the new Beta. As with Aurora, not every new patch
gets into Beta - and the standards for what qualifies to get in are
tighter than with Aurora.
There's the 'Release' release channel, which is what gets published as a
new official Firefox version. Once every six weeks (or thereabouts), the
old Beta becomes the new Release. No patches at all are accepted into
Release, unless a critically urgent oh-shit-that's-bad issue is
discovered and the developers decide to make a "chemspill" point release
(e.g., the difference between 45.0 and 45.0.1).
There's the 'ESR' release channel, which is maintained over roughly a
year-long period. Once every seven Firefox major versions (which come
once every six weeks), a copy of the new Release version becomes the new
ESR. In theory, only security and stability patches make it into the
ESR; new features, and anything which might introduce a regression, are
verboten. (In practice, the developers sometimes don't live up to that
ideal.)
The more you need stability, the lower down this list you should go
with. The newer and faster you need new features and potential bug fixes
(at the risk of new bugs being _added_), the higher up the list you
should go with.
For myself, I always recommend that anyone not actively developing
Firefox should run the ESR.
Thanks for all the details, W! This should definitely come in handy.
