4.3 KiB
TenFourFox "10.4Fx" is designed to be as close to Mozilla sources as possible, for as long as possible. Of course, since our code is not part of the Mozilla Mercurial repo and is simply a local commit, we can also confidently assume that other parts of the tree that we currently rely on for building will disappear as Mac OS X dissolves into that great mug of Cocoa in the sky. Rest assured that 10.4Fx will not be appearing in the Mac App Store any time soon or ever, because we abuse Apple private frameworks, don't build Universal, and still use Carbon API calls for certain portions of code. At some point as APIs break or are inevitably decommissioned by Steve Jobs' talking turtleneck, one day it will no longer be possible to hack Mozilla's code into building directly and our support level will change. This document explains our policies on what to do when that day finally arrives, and what you can expect in general terms down the road.
Support levels for 10.4Fx are defined in terms of "parity," viz., how similar we are to the Mozilla repository we are based on. We've provisionally defined three levels of parity, as follows:
Source parity
This means that we are still building from a Mozilla repository, either the cutting-edge http://hg.mozilla.org/mozilla-central >>> mozilla-central or one of the version branches that they still maintain, using our local changeset for compatibility only. Instead of distributing the entire source, we will simply distribute our changeset and binaries; you clone their repo and apply our changeset to your local repo to build.
This is the current state and the most favourable, as it implies both feature and security parity with official tier 1 Firefox builds. Maintaining source parity as long as possible is goal #1, as when we degrade to feature parity the closer we are to current source the more successful feature updates will be. However, there is a disadvantage in source parity in that it may be harder to integrate custom features. Source parity state is likely to be one to two years, given the pace and nature of previous Mozilla releases.
Feature parity
This means that we are no longer building directly from a Mozilla repository but instead from our own codebase, which was once a Mozilla-supported repo and is no longer (cf. Camino 2.0.x building from Firefox 3.0.19, which has not been supported since March 2010). Since our source is now diverging, we maintain it ourselves. Dropping to feature parity implies that the most current Mozilla as written cannot be hacked to compile anymore. Once we have degraded support to this point, we will maintain our own Mercurial repo with our own changes.
What is likely to provoke this state? Among others, the biggest killers would be requiring a compiler more advanced than gcc 4; requiring the Objective-C 2.x runtime; complete deprecation of Carbon; or requiring hardware OpenGL. These are currently incompatible with the Tiger build system, which 10.4Fx specifically supports.
Still, feature parity implies that we will do our best, within technical limits, to match the feature set of the current Firefox even if we are not using the same source necessarily. This typically involves monitoring Mercurial changesets and Bugzilla bugs for patches, and adapting and/or applying them if they are deemed useful. Only useful or critical features will be so ported, to avoid turning the browser into a series of potentially unstable patches of patches. Security parity, naturally, is considered just this sort of critical patch, but other improvements to rendering and performance will also be considered. Also, feature parity does not preclude implementing our own custom features, since the code base is ours, which is a small advantage.
Security parity
This means the browser has reached a point of maximum technical evolution, either due to completely incompatible code or the processing limits of aging machines, and is the terminal stage of support. Although some custom features may be added, the browser core is essentially in a state of arrested development. However, bugs will still be fixed, and Mozilla security advisories will still be backported such that the browser will still be safe for day-to-day use even if it is no longer evolving technologically. Security parity state will likely persist for several years after source parity has ended.