Macintosh-SW/tenfourfox
1
0
Fork 0
mirror of https://github.com/classilla/tenfourfox.git synced 2024-06-01 17:41:34 +00:00
Code Issues Projects Releases Wiki Activity

add feature parity changes expected

Cameron Kaiser 2016-06-04 16:20:52 -07:00
parent bfbe2ba87d
commit f28399cd40
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Parity.md

@ -14,7 +14,7 @@ After almost seven years, TenFourFox is expected to exit source parity with the
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.
What is likely to provoke this state? Among others, the biggest killers would be 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.
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.