Tonie wrote:Regarding RHEL, version 5 production support ends on march 31 2017, and extended life support on november 20 2020. Just using the production end lifetime, Joomla would have to support PHP 5.3, 5.4, 5.5, 5.6, and any releases on PHP 7 in the beginning of 2017. That would not be a very popular decision with Joomla developers.
I don't disagree, but it's the
users that need to use Joomla. Obviously there's a balance to be struck between users not being inconvenienced and devs not being inconvenienced (and so being driven away), so finding the right balance to strike might be challenging.
CentOS/RHEL 5 is now 2 majors behind, so I suppose a reasonable compromise is current (i.e. 7) + 1. I'd certainly argue that the extended support period shouldn't be factored in.
But It's not just 5 that's locked out by this change, CentOS 6/RHEL 6 are also essentially locked out.
It's not the forum to go in depth, but there may be very good reasons why someone is unwilling/unable to update to CentOS 7 at this point in time.
My customers have already pointed out to me that WP supports anything from 5.2.4 upwards. I know it's something of an apples & oranges comparison, but from their perspective I can understand why it seems more than a little odd. They'll probably come around to understanding it, but I think it's going to take quite a bit to stop them from being dubious about it.
mbabker wrote:As I've noted in this thread, we tried a feature detection implementation with the 3.2.0 release and it fell flat on its face. It created more errors than we could resolve in our code infrastructure and required us backing out a lot of the work that had been done because it was just too complex. With where we are at today, there are no viable options that can safely backport full support for the password hashing APIs to older versions of PHP, whether they are maintained by distros or not. I know this is an unpopular decision, but given our experiences in the BCrypt implementation, I do not see how we can adjust the software platform to work with these distro managed PHP versions in a feasible manner.
I think a good starting place would have been a warning in the backend (whether dismissable or not) rather than outright refusing to run. Manually disabling/nobbling the version check would be the equivalent, but will need repeating every time they update, so it's not the greatest solution. Whether or not things break after that, becomes the operators issue (so long as things fail sanely).
What the current change
has succeeded in doing is encouraging users to implement some potentially hacky workaround to get it working.
Taking the SCL method as an example. It's a RH supported repo, so should be safe - except of course that if you want to use it (without making 5.4 the primary version of PHP) you need to bring mod_cgi into the mix. So now your exposure to vulnerabilities is Joomla + PHP + mod_cgi + base stack.
I don't pretend to know the exact answer, and I appreciate you're trying to keep code complexity down, but given that RH holds an estimated 65% of the server market, it's not a good distro to have locked out.
The bit I'm
really struggling with though, is the effect the change has on confidence in the future supportability of Joomla. Can we expect to see a similar dramatic change in the future?
It's one thing to find a way around it this time, but if it's suddenly decided to require (for example) 5.5 as a minimum in (for example) 18 months time, then at that point you're again looking at abandoning a supported mainstream distribution for the sake of a single CMS (I chose 5.5 because CentOS/RHEL 7 is 5.4 so would again be blocked).
Although I disagree with the decision, what it really boils down to is customers start getting unhappy when they have to pay for things like a major OS upgrade before it's even close to officially being needed. The customer in this case has already floated the idea of a migration to a different CMS in the medium to long-term, and I'm having problems finding fault with some of their concerns.
They chose a long-term support distribution for good reason, and though they'll likely swallow the cost this time round, they're eyeing the exits. Ideally, I'd like to avoid that, but an argument that they should move onto a less stable distro just isn't going to win
Tonie wrote:The one thing that I could think of is that a number of 3rd party developers who find this feature important create a separate "Joomla extra long support" distribution of one Joomla version, and support that for a number of years.
The thing is, supporting current versions of distributions shouldn't be considered a 'feature'. The codebase on RHEL 6 isn't out-of-date, though the feature set may well be.
Not to mention, RHEL 7 (PHP 5.4) was released 10 June 2014. The changes we're talking about were rolled out in Joomla 3.3 - 30 Apr 2014. So the at the time of the change, CentOS/RHEL 6 (PHP 5.3.3) was the latest version available.
Again, that gives rise to concerns of what happens when 7 is a bit older, will it suddenly be locked out of future Joomla updates because the goalpost has moved again?