-
Notifications
You must be signed in to change notification settings - Fork 5
Upstream sources and releases
A short introduction of how Mozilla releases Firefox
The main releases come every 6 weeks, being reduced step by step to 4 weeks, with Tuesday being the release date. Sometimes this is shifted (usually one week ahead) when it would collide with public vacation.
When Mozilla decided to change the release cycle (or more precisely to introduce a regular one - more on that below), the outcry from enterprise users made it create additional release channel called ESR (Extended Support Release) which is synchronized with the main one every nine months and receives only security updates between the syncs.
Apart from that, when Firefox got split off the original Mozilla codebase, people caring for the messaging part of the project continued development synchronizing with the browser development.
Holds Firefox and Gecko.
Holds Thunderbird, SeaMonkey, calendars, etc.
Releases branch off of this repository. Also known as "Trunk". "Stable development" (it has some pre-stages as well, these are not important now though), this is where nightly builds are sourced from. Some people are brave enough to run it, but there are good reasons why it is called "minefield".
Testing the next version of Firefox before it becomes the official release. Beta 1 and Beta 2 are built from this beta branch and used to build and ship Firefox Developer Edition as a stabilization step before shipping Firefox Beta to a much wider Beta audience.
What is used to build the thing most people run.
As above, with the exception that features appear in large bulks every 9 months and not 6 weeks. Advantages for site-wide deployments (which often requires comprehensive web application testing) are obvious. Also, since there is a two cycle (3 months) overlap between the successive ESR releases it allows some testing before upgrade is mandated by security concerns.
Good news is that for SLE we only package Firefox ESR.
Current development of nss, nspr, etc.
Note: There is an ESR version of NSS and a "stable" version. The ESR-version is the one shipped with Firefox ESR. But SUSE/openSUSE usually just update to the latest "stable" NSS-release when an update is necessary, but in theory one could just as well update to the latest NSS ESR version instead. Not sure if anybody has tried that in a while, though.
L10n infrastructure projects, as well as compare-locales script
"Trunk" of l10n repos
Not sure if this is used anymore. It is older than commits in mozilla-release. Supposed to be the localizations for mozilla-beta.
Localizations for mozilla-release. ESR shares these. (For the localizations I'm not aware of any other way to clone all the repositories than to (semi-)manually cloning them one by one from the list at http://hg.mozilla.org/releases/l10n/mozilla-release.)
Localisations are not regularly tagged - the authoritative information is in JSON files at https://product-details.mozilla.org/1.0/l10n/ which lists appropriate revision IDs for each language for each product.
The same information is contained in the released tar-ball under browser/locales/l10n-changesets.json.
For ESR channel this should be constant throughout its lifetime (so ESR version X.Y.Z will be using l10n from version X).
- To safe time when packaging, check if the new version updated its locale at all, by comparing the json-files.
The changelog has to contain all CVEs fixed. These can be found here: https://www.mozilla.org/en-US/security/advisories/
But it is easier to check out this git-repo (or once checked out, update):
git clone https://github.com/mozilla/foundation-security-advisories.git
under announce/ the yaml-files can be found.
Understanding source structures
Packaging
Debugging
Debugging Firefox with QtCreator
Additional info