MozillaWiki

Global:1.9 Trunk 1.8 Branch Plan

Revision as of 00:34, 13 December 2005 by Brendan (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Problem Statement

  • Ship Firefox 2 no later than Q3 2006 and Firefox 3 no latter than Q1 2007
    • Shipping earlier is possible, later is to be avoided at all cost
    • Show front-end innovation in Firefox 2 while building it on a more stable back-end platform
    • Make long lead-time, major architectural advances in graphics and content languages in Gecko 1.9 for Firefox 3
  • Avoid requiring developers to merge and land changes in two places (trunk and a major branch)
    • Merging means diverging, which implies conflicts
    • Merging by hand is hard, errors are likely
    • Developers may just forget to land in one place, or decide not to
  • Avoid deferred "big bang" landings in any place
    • To maximize testing of continuously integrated changes
    • While minimizing regression checkin-window size
  • Keep sufficient community QA focus on 1.9 while 1.8 receives "next release" testing priority
    • Necessary during release from branch to "bake" candidate changes
    • Gecko 1.9 / Firefox 3 schedule will slip if trunk regresses too much during Firefox 2 development

Proposed Solution

  • The 1.8 branch has already branched a 1.8.0 sub-branch for patch releases
    • These 1.8.0.x releases will ship every 6-8 weeks
    • They will fix severe reliability bugs (security, crash, even compatibility)
    • Number of fixes limited by time available to QA each patch
  • Firefox 2 will come from the 1.8 branch, eventually branching for release and further maintenance as 1.8.1
    • This 1.8.1 number matters to content authors who detect Gecko rv: in User-Agent headers.
    • The goal is to fix only Gecko bugs that require no content changes
      • All crash, dataloss, leak, and security fixes from 1.8.0.x releases
      • Backward compatibility means not breaking old workarounds for 1.8 bugs
    • New Firefox 2 features requiring back end changes should be minimized
      • Or recast in terms of back end extensions that are purely additive
      • Some amount of intentional API breakage is planned (e.g. History and bookmarks APIs)
    • No APIs marked @status FROZEN should be changed on any 1.8.x branch
  • Firefox 3 will develop on the trunk, which is in 1.9 alpha stage
  • The trunk hosts continuously integrated and tested rearchitecture work
    • Graphics reimplemented on top of Cairo
    • New XUL features and XUL box layout specification/standardization
    • Embedding and XUL App API and implementation unification
    • Layout "reflow" rearchitecture
    • JavaScript1.9 leading to JS2 / ECMA-262 Edition 4.
    • Python for XUL
    • etc. -- see the [[Roadmap_Scratchpad|Roadmap Scratchpad]
  • The trunk is never significantly broken for long
    • "Significant" meaning developers can't work or dogfood on the trunk
    • Back-out of rapid fixing upon regression identification is the rule
    • All major rearchitecture must land in well-tested pieces
    • Again, the main purpose of the trunk is to continuously integrating new work, to maximize QA coverage and minimize regression check-in windows
    • Mistakes will be made, but planned landings with back-out options will minimize (not eliminate) distributed discomfort
  • How to land changes once for both places
    • We will extend CVS commitinfo and bonsai to automate synchronization of files between trunk and the 1.8 branch
      • The synchronization can be specified for source repository subtrees such as browser, mail, xpfe, toolkit, extensions/inspector, etc.
      • Exception lists per directory may be supported if necessary
      • Developers are expected to test appropriately to avoid breaking trunk or 1.8 branch
    • All Firefox 2 changes will land on the trunk as well as the 1.8 branch
    • Some Firefox 2 code will need to be #ifdef MOZILLA_1_8_BRANCH to cope with API or bug-compatibility skew between trunk and branch
    • Some Firefox 3 changes will be needed by Gecko 1.9 back end changes (e.g. for XUL box layout standardization) -- these must be #ifndef MOZILLA_1_8_BRANCH
    • The MOZILLA_1_8_BRANCH macro will be defined for C++ and XUL on the branch
      • After Firefox 2 ships, #ifdefs testing this macro will be purged from the trunk
      • We'll use an automatic unifdef program to avoid fat-finger errors

A Dialog, or FAQ

Retrieved from "https://wiki.allizom.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan&oldid=14979"