Skip to content
Cameron Kaiser edited this page May 31, 2017 · 4 revisions

TenFourFox "10.4Fx" was 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. Some of this has already happened, but fortunately we have a plan.

We define our support levels for 10.4Fx 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 meant that we still built the browser from a Mozilla repository, typically the most recent Extended Support Release (ESR), using our local changeset for compatibility only. Instead of distributing the entire source, we simply distributed our changeset and binaries; you would have cloned their repo and applied our changeset to your local repo to build.

After almost seven years, TenFourFox exited source parity with the end of support for the Firefox ESR 45 branch in June 2017.

Feature parity

This is the current state of TenFourFox. This parity level indicates 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. Dropping to feature parity implies that the most current Mozilla as written cannot be hacked to compile anymore, so since our source is now necessarily diverging, we maintain it in our own repository ourselves.

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, non-security bugs will still be fixed to the extent possible, 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.

You can’t perform that action at this time.