Mozilla plans to switch to more frequent Firefox releases in order to provide frequent improvements to users, without disrupting longer term work.
This page points you to canonical information sources and current discussions where possible. If something is not finalized or started, owners are attempted to be listed. Read the following two documents first.
If you want the shortcut, there is a FAQ
A summary of the process is at: http://mozilla.github.com/process-releases/draft/development_overview/
A detailed process plan is at: http://mozilla.github.com/process-releases/draft/development_specifics/
Both are available in git so you can track changes: http://mozilla.github.com/process-releases/
Please direct discussion to the dev-planning mailing list: https://lists.mozilla.org/listinfo/dev-planning
Firefox 5 State
This is a list of actions that have been taken for FF5. Differences or potential differences due to ongoing discussions in future releases (post FF6 and beyond) will be noted.
- FF5 work is now occurring on the mozilla-beta repository
- Patches need mozilla-beta-approval+ flag set in bugzilla to land
Version and User Agent
- version number is 5.0 for both Firefox and Gecko on mozilla-beta
Bugzilla and Triage
- mozilla5 target milestone for mozilla-beta
- Issues that need to be reviewed for stabilization should be set to tracking5? in bugzilla
- Patches that want landing need to set mozilla-beta-approval? in bugzilla
- Queries for triage are at: Firefox/Beta
Merge and Release Dates
These are planned branch migration dates based on the current Development Specifics draft. They may change if the process changes. Note: Code is not always released to users on the same day as the branch migration. The release to users may be a few days later, to allow for manual testing and sign-off.
- 2011-06-21: Firefox 5 -> mozilla-release
- 2011-07-05: Firefox 7 -> mozilla-aurora; Firefox 6 -> mozilla-beta
- 2011-08-16: Firefox 8 -> mozilla-aurora; Firefox 7 -> mozilla-beta; Firefox 6 -> mozilla-release
- 2011-09-27: Firefox 9 -> mozilla-aurora; Firefox 8 -> mozilla-beta; Firefox 7 -> mozilla-release
...and so on, every six weeks. For more past and future dates, see /Calendar.
This section documents key discussion points and proposals that are in progress or need to happen. It also notes anything unclear. Where possible, it documents owners who need to give input and/or drive the item to conclusion.
Development Specifics [legneato]
These are highlights of discussion going on in the dev-planning mailing list related to Christian's document at: http://mozilla.github.com/process-releases/draft/development_specifics/
- Proposed to stabilize the version in the User Agent - for instance even in aurora it would say Firefox/5.0
L10N and I18N [legneato, smooney, axel, choffman, christian]
- how to ensure minimal churn and max translation time
- l10n repository naming
- Axel proposal
Security Updates [chofmann, dveditz, legneato]
- the priority is last release branch
- we fix on all branches
- needs follow up on shadow repo possibilities
- proposal to merge mozilla-shadow to mozilla-central just before the merge to mozilla-aurora - since we want it in both places anyhow
- Current proposal is no 5.0.x, 6.0.x etc updates other than chemspills
- based off the 6 week m-c pull cycle
- each release can be marketed in a different way
- Needs re-evaluation at FF6 to mozilla-aurora pull
Channel Distribution [smooney, rs, limi]
This is about how to divide up beta users into multiple testing channels for -aurora and -beta. There are decisions about how to divide up the user base and there are supporting code changes to make this happen.
- Meetings to work on this are at Firefox/Features/ChannelSwitching
- Supporting code tracked in bug 386760
- Better discoverability of version information for SUMO, Input, Bugzilla as we break these apps bug 648444
Repository Mechanics [joduinn, legneato]
How to name branches, particularly release branches.
- Branch naming proposal John O'D
How to do chemspills on releases.
Proposal by joduinn:
- The Chemspill fix will be landed as follows:
- mozilla-central (as usual)
- in the release repo; generate builds, QA and ship asap
- in the beta repo; generate builds, QA and ship asap
- in the aurora repo; generate builds
- landing this same fix in 4 places like this means we protect *all* our users asap.
- this prevents possible "forgetting" a fix, when a later release moves from m-c->aurora or aurora->beta or beta->release.
- this is similar sequence to the land-three-times model we used before: m-c, then release, then beta. Only addition is new aurora repo.
Triage & Tracking [smooney]
- Approvals proposal: http://groups.google.com/group/mozilla.dev.planning/msg/eaff6f18d32ee1b5
- Tracking proposal: http://groups.google.com/group/mozilla.dev.planning/msg/595242c231c97f45
- bug 648555
- Original proposal from Beltzner http://groups.google.com/group/mozilla.dev.planning/msg/94a8ac4da1a43531
Add On Compatibility [fligtar, jorge]
- Proposal at http://groups.google.com/group/mozilla.dev.planning/msg/bf3afa87ab8f5eaa
- recompile forced for FF5 already http://hg.mozilla.org/mozilla-central/rev/200a746e0fac
QA [rob, matt]
- as QA gets inserted, need clear suspension/resumption criteria for conflicts like chemspill vs release
- beta feedback is a big chunk of is it shippable feedback, and we are reducing it
Feature Planning [dria]
Because of timelines, this process will not impact Firefox 5 very much, but should be come much more important in FF6 and full formed for FF7.
Development Best Practices [engineering teams]
Features must be "ready" for landing on mozilla-central, in general this is up to module owners, sheriffs and teams, but building a set of best practices would be ideal.
- possibly increased use of project branches
- kill switch removal http://groups.google.com/group/mozilla.dev.planning/msg/3a8e2c6c72cc2fff
4.0.x and Previous Releases [joduinn, ]
This section clarifies some questions that have come up about the relationship between Firefox 4 and older and Firefox 5.
- 5.0 and newer processes will not be "backported" onto 4.0.x and older releases
- there will be 4.0.x releases and chemspill handling
- branch team is taking over for 4.0.1
- there will be 3.6.x and 3.5.x releases and chemspill handling
- As part of the faster cadence, FF5.0 automatically EOL's when FF6.0 is released with users getting silent updates.
- For the previous FF4.0.x, FF3.6.x, FF3.5.x releases, we had different policy in place at the time of release. While there were problems with the previous policy, we still need to respect other projects (and the users) that still depend on these older code lines.
- We need a working policy for when to end-of-life these 3 older release branches
- how much longer do we plan to generate security releases for these?
- what is the deciding metric to use to cutoff? By time? by "number of users remaining"? By "% of overall userbase"?
- any metric that measures number of users remaining needs to also include specific cadence for prompted/advertised Major Updates.
Update: EOL of Firefox 3.6 is 24th April 2012 (see ESR).