Confirmed users, Bureaucrats and Sysops emeriti
2,976
edits
m (Reverted edit of Nidhal, changed back to last version by Km1316) |
|||
| Line 26: | Line 26: | ||
(Thanks to Asa for this artwork.) | (Thanks to Asa for this artwork.) | ||
= Proposed Solution = | |||
* The 1.8 branch has already branched a 1.8.0 sub-branch for patch releases | |||
** No checkin without approval via bugzilla flag set by drivers | |||
** 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 | |||
** The 1.8 branch will eventually branch for Firefox 2 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 bugs that require no Web 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. [[Places|History and bookmarks APIs]]) | |||
** APIs marked @status FROZEN must not be changed on any 1.8.x branch | |||
** Changing other unfrozen APIs requires drivers approval (details TBD) | |||
* Firefox 3 will develop on the trunk, which is currently in [[Gecko 1.9 Alpha Planning]] 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 [[Gecko 1.9 Roadmap]] and [[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 or 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 integrate 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 = | = A Dialog, or FAQ = | ||