oh totally missed this one... let me use my time machine... go with official support for php; 5.6 is out of support, sure redhat has some veeery long TS but that doesn't mean every software gets updates, that's why compiling your stuff on redhat/centos servers has been a thing to know ^^ make a branch, old versions gets critical security fixes only, if someone really needs new stuff in old setups => minimum would be 1yr subscription. One could aswell argue 5.6 gets kind of support by one debian guy ... but well min req. 5.6 would've been ok. 3.2 depending on release at least 5.6. You can't be so much enterprise to use such old versions and pay no money ^^ centos users are thought to use epel from the beginning anyway
There are no functions that we need in PHP > 5.3.x at the moment, so why shall we disallow old PHP versions without need. If there is something in a newer PHP version that we really need, then we will reconsider the requirements of course. And yes, we have a lot ISPConfig business users with LTS OS versions and we will not refuse updates to them without need as that's one reason why companies chose ISPConfig over other OS hosting panels.
ah I see, thought old php would be a deal breaker. well it's late, should :goto whereIcameFrom ^^ but first I need to fix the issue regarding your git lmtp patch and opendmarc milter ignoring everything now b/c it's from 127.0.0.1 but this python dns issue... dang it debian. couldn't be more OT sry
Basically, the new PHP versions cause us more trouble than the old ones Especially PHP 7.1 as the PHP dev's force us to rewrite a lot of code like the Mysql library due to their new restrictions in function overloading. But that's a different thing and we are working to fix it.
ha, tell me about it - I got a bunch of software ( others wrote ) I'm doomed to fix ^^ some of them use ioncube ... so compiling php 5.2 without ssl support is something one has to do from time to time... no support for security on that but... customer is king