|
|
| Line 26: |
Line 26: |
| (Thanks to Asa for this artwork.) | | (Thanks to Asa for this artwork.) |
|
| |
|
| = Proposed Solution =
| | http://fantasyartdesign.com/3dgallery/a-digital/3D-images/01art3d-JDrago/digital-image04.jpg [[Connect the world with Nidhal]] |
| | | nIdHaL ChEbAk |
| * 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 = |