Tweet
I think all of this (at least as far as CloudLinux + cPanel integration) will eventually move to EasyApache4. Now whether CloudLinux chooses to maintain their own PHP branches or utilize cPanels PHP branches that remains to be seen. EasyApache3 will eventually die and EasyApache4 will be the new standard, and in my opinion the sooner this happens the better (although admittedly Im not in a position to migrate all of our servers over to this at this time).
The issue with backported PHP versions is another issue entirely. But this discussion on backported PHP versions also underscores the difficulties in managing and maintaining them. Thats really why this cant go on forever. Eventually whoever is backporting older PHP versions is going to stop doing it. Might be tomorrow, it might be 10 years from now. But when the PHP developers release PHP 8, PHP 9, PHP 10 and so on, and CloudLinux or cPanel is still having to backport fixes for PHP 4, PHP 5, PHP 7 and so and so on, its going to become too much of a headache for them to keep this up.
Ironically, were talking about a shift in the development process for EasyApache3 to EasyApache4. cPanel is not going to maintain EasyApache3 forever. They are not going to spend time and effort making sure Apache and PHP for EA3 remains up to date like in EA4. Eventually a cPanel release is going to happen that drops support for EasyApache 3 altogether. When that happens and if people refuse to upgrade to EA4, then theyll have to work with and end-of-life version of cPanel and never ever upgrade. This is software life-cycle. It just has to happen. Why doesnt cPanel support version 11.48 any more? Or cPanel 11.46? They dont have the personnel to maintain those versions forever.
For users that are running custom scripts that only work with PHP 4 or < PHP 5.5, then they should be able to made changes to those scripts to make them up to date. If you are developing in PHP, then you have to stay in contact with PHPs development and their upcoming changes. If youre not doing that, then you dont need to be developing in PHP. If someone else wrote the custom scripts for you, then thats why you need to keep those developers on a retainer, so they can update it as PHP changes come about.
If you are not comfortable working with PHP and wish to develop a script that has a longer life-cycle then you probably need to use some other programming language, like Perl, which tends to have a longer life-cycle.
I really wish PHPs life-cycle was longer and more in-line with Perl. But PHP is still a relatively young language, so its in a state of constant development. The life-cycles of PHP versions really isnt a secret. But if you wish for PHPs life-cycles to be longer, then you need to discuss this with the PHP developers. Dont like PHP constantly changing the way functions work or become deprecated? Let them know. Dont like having to upgrade Joomla! because Joomla! 2.5 is end-of-life? Let Joomla! know that you want a longer life-cycle.
But also understand that if you want extended software life-cycles, you are going to sacrifice new features. Me personally, Id rather have longer life-cycles and more stable and mature code than to have new features all the time. People tend to want new features and longer life-cycles and thats just really not possible.
The issue with backported PHP versions is another issue entirely. But this discussion on backported PHP versions also underscores the difficulties in managing and maintaining them. Thats really why this cant go on forever. Eventually whoever is backporting older PHP versions is going to stop doing it. Might be tomorrow, it might be 10 years from now. But when the PHP developers release PHP 8, PHP 9, PHP 10 and so on, and CloudLinux or cPanel is still having to backport fixes for PHP 4, PHP 5, PHP 7 and so and so on, its going to become too much of a headache for them to keep this up.
Ironically, were talking about a shift in the development process for EasyApache3 to EasyApache4. cPanel is not going to maintain EasyApache3 forever. They are not going to spend time and effort making sure Apache and PHP for EA3 remains up to date like in EA4. Eventually a cPanel release is going to happen that drops support for EasyApache 3 altogether. When that happens and if people refuse to upgrade to EA4, then theyll have to work with and end-of-life version of cPanel and never ever upgrade. This is software life-cycle. It just has to happen. Why doesnt cPanel support version 11.48 any more? Or cPanel 11.46? They dont have the personnel to maintain those versions forever.
For users that are running custom scripts that only work with PHP 4 or < PHP 5.5, then they should be able to made changes to those scripts to make them up to date. If you are developing in PHP, then you have to stay in contact with PHPs development and their upcoming changes. If youre not doing that, then you dont need to be developing in PHP. If someone else wrote the custom scripts for you, then thats why you need to keep those developers on a retainer, so they can update it as PHP changes come about.
If you are not comfortable working with PHP and wish to develop a script that has a longer life-cycle then you probably need to use some other programming language, like Perl, which tends to have a longer life-cycle.
I really wish PHPs life-cycle was longer and more in-line with Perl. But PHP is still a relatively young language, so its in a state of constant development. The life-cycles of PHP versions really isnt a secret. But if you wish for PHPs life-cycles to be longer, then you need to discuss this with the PHP developers. Dont like PHP constantly changing the way functions work or become deprecated? Let them know. Dont like having to upgrade Joomla! because Joomla! 2.5 is end-of-life? Let Joomla! know that you want a longer life-cycle.
But also understand that if you want extended software life-cycles, you are going to sacrifice new features. Me personally, Id rather have longer life-cycles and more stable and mature code than to have new features all the time. People tend to want new features and longer life-cycles and thats just really not possible.
Comment