Confirmed users, Bureaucrats and Sysops emeriti
419
edits
Global:1.9 Trunk 1.8 Branch Plan: Difference between revisions
Global:1.9 Trunk 1.8 Branch Plan (view source)
Revision as of 00:42, 13 December 2005
, 13 December 2005→Proposed Solution
| Line 33: | Line 33: | ||
** No APIs marked @status FROZEN should be changed on any 1.8.x branch | ** 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 | * Firefox 3 will develop on the trunk, which is in 1.9 alpha stage | ||
* The trunk hosts continuously integrated and tested rearchitecture work | ** The trunk hosts continuously integrated and tested rearchitecture work | ||
** Graphics reimplemented on top of Cairo | *** Graphics reimplemented on top of Cairo | ||
** New XUL features and XUL box layout specification/standardization | *** New XUL features and XUL box layout specification/standardization | ||
** Embedding and XUL App API and implementation unification | *** Embedding and XUL App API and implementation unification | ||
** Layout "reflow" rearchitecture | *** Layout "reflow" rearchitecture | ||
** JavaScript1.9 leading to JS2 / ECMA-262 Edition 4. | *** JavaScript1.9 leading to JS2 / ECMA-262 Edition 4. | ||
** Python for XUL | *** Python for XUL | ||
** etc. -- see the [[Roadmap_Scratchpad|Roadmap Scratchpad] | *** etc. -- see the [[Roadmap_Scratchpad|Roadmap Scratchpad] | ||
* The trunk is never significantly broken for long | ** The trunk is never significantly broken for long | ||
** "Significant" meaning developers can't work or dogfood on the trunk | *** "Significant" meaning developers can't work or dogfood on the trunk | ||
** Back-out of rapid fixing upon regression identification is the rule | *** Back-out of rapid fixing upon regression identification is the rule | ||
** All major rearchitecture must land in well-tested pieces | *** 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 | *** 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 | *** 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 | ** 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 | *** 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. | *** 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 | *** Exception lists per directory may be supported if necessary | ||
*** Developers are expected to test appropriately to avoid breaking trunk or 1.8 branch | *** 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 | ** 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 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 | *** 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 | *** 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 | *** 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 | *** We'll use an automatic unifdef program to avoid fat-finger errors | ||
= A Dialog, or FAQ = | = A Dialog, or FAQ = | ||