|
|
| (58 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| = Overview =
| | #REDIRECT [[Release Management/Release Process]] |
| Mozilla's plan is is to introduce much faster Firefox releases in order to provide more 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.
| |
| | |
| A draft summarizing the process is at:
| |
| http://mozilla.github.com/process-releases/draft/development_overview/
| |
| | |
| A detailed process plan is being worked on by Christian and Sheila:
| |
| 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.
| |
| | |
| === mozilla-central ===
| |
| * open for a 3 week period starting March 23 and ending April 12
| |
| ** NOTE: will 6 weeks in future releases
| |
| * build sheriffing will focus on high gain, low risk items
| |
| ** see bsmedberg for questions
| |
| ** tree is closed when there is no sheriff
| |
| * cedar is being run by Ehsan and is being used for checking-needed bugs
| |
| | |
| === Version and User Agent ===
| |
| * version number of 2.2a1pre/4.2a1pre
| |
| ** NOTE: Versioning under discussion
| |
| * historical user agent string, ie
| |
| Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110330 Firefox/4.2a1pre
| |
| ** NOTE: Changes to user agent string under discussion
| |
| | |
| === Bugzilla ===
| |
| * mozilla2.2 target milestone for mozilla-central
| |
| ** NOTE: May change do to version number changes and/or triage process changes that are in discussion
| |
| | |
| === Nightlies & Beta Channel ===
| |
| * Nightlies stay on mozilla-central
| |
| * Beta users stay on beta channel with no updates
| |
| ** NOTE: This will change either with progress on 4.0.1 or with channel discussion finishing
| |
| | |
| = 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/
| |
| | |
| === Versioning ===
| |
| * Must be consistent and predictable
| |
| ** Teams outside of engineering must know what is coming - metrics, SUMO, socorro,input
| |
| * 3 versioning proposals
| |
| ** Chrome Style
| |
| *** May bloat changelog with constant version bumps
| |
| **** Could be done outside hg, not clear if this is a good idea
| |
| *** Does this make tracking regressions to an exact commit set easier?
| |
| ** Standard8 (Mark Banner):
| |
| *** No easy way to map version to channel
| |
| ** KaiRo (Robert Kaiser):
| |
| *** http://groups.google.com/group/mozilla.dev.planning/msg/6620437b05dc410c
| |
| * Need to ensure that teams such as metrics, SUMO, socorro, input can access detailed version info
| |
| ** js property, whitelist, user prompt (like geolocation)
| |
| * versioning in project branches and local builds should have a sane default that doesn't conflict with automated build system numbering
| |
| | |
| ==== Gecko Versioning ====
| |
| * Proposed to sync this with Firefox version
| |
| ** Need to check with other consumers like Thunderbird about this
| |
| * Current system supports detaching Firefox from platform releases, which is called out in Christian's doc
| |
| | |
| ==== User Agent ====
| |
| * Proposed to stabilize the version in the User Agent - for instance even in experimental 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
| |
| ** http://groups.google.com/group/mozilla.dev.planning/msg/8e660e18b6daf4f4
| |
| | |
| === Builds ===
| |
| * Are beta channel builds signed?
| |
| | |
| === Security Updates [chofmann, dveditz, legneato] ===
| |
| * the priority is last release branch
| |
| ** we fix on all branches
| |
| * needs follow up on shadow repo possibilities
| |
| | |
| === 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-experimental pull
| |
| | |
| == Meetings ==
| |
| * How does current meeting structure need to change for the new process?
| |
| ** Where and when do go/no-go decisions get made
| |
| ** Where and when is blocker triage done
| |
| | |
| == Channel Distribution [smooney, rs, limi] ==
| |
| | |
| This is about how to divide up beta users into multiple testing channels for -experimental 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 ups
| |
| | |
| == Repository Mechanics [joduinn, legneato] ==
| |
| | |
| === Branch Naming ===
| |
| How to name branches, particularly release branches.
| |
| | |
| * Branch naming proposal John O'D
| |
| ** http://groups.google.com/group/mozilla.dev.planning/msg/30c67403ddad9a7e
| |
| | |
| === Merging ===
| |
| How to do the merge to downstream branches from a mechanical standpoint.
| |
| | |
| * Do not delete experimental, merge from m-c
| |
| * track to see how much of a problem we get with backouts/preffing off
| |
| * the first merges will be manageable
| |
| | |
| === Chemspill ===
| |
| | |
| How to do chemspills on releases.
| |
| | |
| * Still wide open.
| |
| | |
| == Blocker Tracking ==
| |
| * Proposal for flags from Beltzner
| |
| ** http://groups.google.com/group/mozilla.dev.planning/msg/94a8ac4da1a43531
| |
| | |
| == Add On Compatibility [fligtar, jorge] ==
| |
| * reducing breakage and retaining compatibility
| |
| ** IDL file diff possibility to notify people proactively
| |
| * 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.
| |
| | |
| * [[Firefox/Features List]]
| |
| * [[Firefox/Flight Tracking]]
| |
| | |
| == 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
| |
| * [[RapidRelease/LandingPlan]]
| |
| * kill switch removal http://groups.google.com/group/mozilla.dev.planning/msg/3a8e2c6c72cc2fff
| |
| | |
| == Platform Consumer Outreach [jpr, kev] ==
| |
| * Linux distribution that need to be prepared for speed of shipping
| |
| * ATV outreach (screen readers, etc)
| |
| | |
| = Cheat Sheet =
| |
| | |
| This is a list of key items that were discussed and are now at consensus or near-consensus. A Cliff Notes if you will of the key changes in the development process - '''refer to the documents in the Overview for all the details'''
| |
| | |
| == Mini-Glossary ==
| |
| * '''Stabilization''' is the process of backing out and preff-ing off features and changes
| |
| * '''Downstream Repository''' is the repository from which an antecedent or '''Upstream Repository''' is merged to, for instance mozilla-experimental is the downstream repository for mozilla-central in the current
| |
| | |
| == Repositories ==
| |
| * mozilla-central merges to mozilla-experimental every 6 weeks
| |
| * Stabilization occurs after the pull to the downstream branch
| |
| * A bug fix for any repository (for instance mozilla-beta) lands in all upstream repositories at same time as well
| |
| | |
| == Feature & Major Change Policy ==
| |
| * All features and major changes should be kill switched and/or easy to back out
| |
| * Where possible forward proofing should be employed (config, data)
| |
| ** at most backward and forward one version ie experimental vs mozilla-central
| |
| * developer takes the pain of backing out!
| |
| | |
| = 4.0.x and Previous Releases =
| |
| | |
| 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
| |