From: David K. <da...@ke...> - 2019-08-13 16:56:21
|
This feels like something that we should create a GitHub branch for and take our time over. Since moving our source to GitHub we really have not taken advantage of its development features. We don't use branches, issues, pull requests, etc. I propose creating a branch specifically to work the can of worms. Leave Master branch stable, continue to apply fixes to it, etc. But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them. Once thoroughly tested we merge everything back into the master. We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5). David On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote: > > > > On Aug 13, 2019, at 2:50 AM, Michael Knill < > mic...@ip...> wrote: > > > > Hi Devs > > > > Just wondering if/when we would be looking to go to PHP 7.x considering > 5.6 was EoL at the beginning of this year? > > I understand that PHP 7 is much faster than 5.6 so it will make some of > my busy XML apps a little better. > > Hi Michael, > > Indeed, this is a can-of-worms. > > 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release > cycle is to introduce a new version every year, with new bugs ... fixes for > two years plus security-only fixes for a year. Rinse and repeat. > > https://www.php.net/supported-versions.php > > Our current 5.6 version was the closest to LTS they have offered. Note a > LTS series is of higher quality since it is scrutinized for a longer period > of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at > 9 x-releases. > > BTW, each new PHP release is not 100% backward compatible. > > > 2) Sadly, PHP includes the timezone data within the php binary rather than > using the Linux /usr/share/zoneinfo data. This is extra bloat for standard > 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, > more significant extra bloat. > > Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger > https://bugs.php.net/bug.php?id=69652 > > We currently work around this by compiling our own 32-bit only > "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb > maintainer) used. This keeps the PHP 5.6 timezone data in sync with the > latest Linux zoneinfo data. > > It appears later PHP versions use the same timezonedb.h file, though some > details may have changed. > > > 3) A jump to PHP 7.3 would no doubt introduce some backward > incompatibilities with the web interface, warnings at the very least. > > > 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 > issues, but fixes could be cherrypicked from upstream phpLiteAdmin. > > > That is a summary for the can-of-worms. > > Fortunately with AstLinux, PHP is not exposed to untrusted users by > default, and it is highly recommended to not expose HTTP/HTTPS to anything > other than trusted endpoints ... thereby limiting PHP's security exposure. > > BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a > PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six > years beyond its EOL. > -- > m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014 > -- > > At some point we will need to make a version jump of PHP, but we are > currently on solid ground and somewhat uncertain how we might land if we > made the jump. > > As always, open to comments. > > Lonnie > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |