Macintosh-SW/tenfourfox
1
0
Fork 0
mirror of https://github.com/classilla/tenfourfox.git synced 2025-01-12 20:30:18 +00:00
Code Issues Projects Releases Wiki Activity

hello FPR

Cameron Kaiser 2017-05-30 21:26:47 -07:00
parent c103292530
commit df33a6f1a3
1 changed files with 6 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Parity.md

@ -1,22 +1,18 @@
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, 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.
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.
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:
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 means that we are still building 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 will simply distribute our changeset and binaries; you clone their repo and apply our changeset to your local repo to build.
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.
This is the current state and the most favourable, as it implies both feature and security parity with official tier 1 Firefox ESR 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.
After almost seven years, TenFourFox is expected to exit source parity with the end of 45ESR support in August 2017.
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 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. 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.
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.
What is likely to provoke this state? Currently, Mozilla's requirement for Electrolysis multiprocess support cannot be built on 10.4 and has known problems even with 10.6 (which Mozilla also no longer supports). Electrolysis is expected to be a build-time requirement by 52ESR. In addition, Mozilla is converting some components of the codebase from C++ to Rust, which has no native compiler or runtime on any version of PowerPC OS X. Several of these components are also expected to be build-time requirements by the next ESR.
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.
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**