Personal tools

RapidRelease

From MozillaWiki

Revision as of 11:21, 18 January 2012 by Hartnegg (Talk | contribs)

Jump to: navigation, search

Contents

Overview

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.

Repositories

  • 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.

Current Discussions

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/

User Agent

  • 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]

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

Release Updates

  • 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

Meetings

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.

Repository Mechanics [joduinn, legneato]

Branch Naming

How to name branches, particularly release branches.

Chemspill

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

Notes:

  • 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]

Add On Compatibility [fligtar, jorge]

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.

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

End-of-Life:

  • 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).