At the moment we have a PHP cycle of 1 year per minor version which is supported for 3 years.
I personally like the idea to stop supporting old php version as soon as they are EOL, but to be realistic I'm sure not all installation can/will follow this release cycle.

For example Debian, they will support

• Jessie till June 2020 which include PHP 5.6
• Stretch till 2022 which includes PHP 7.0
• Buster has no release date yet (around mid 2019)+5 years and will hopefully include PHP 7.2

That means till 2024 we have to support (following the Debian release cycle) at least PHP 7.2 while PHP 8.0 is 3 years old and already obsolete.

(all dates are guesses)

I'm very torn between sticking with what we promised and forcing people to update. Considering all the workarounds that we had to do because of old PHP versions, I'm leaning towards updating our PHP requirements. I actually would create an automatism here.

"We support PHP version X. If version X reaches its EOL, we support it for another timeframe Y and then go to the next minor version. Major PHP version changes can only be done with a major version bump."

So for 3.x and an additional support of 2 years, we would have initially supported 5.3 and now would push for 5.5 at least. In (coincidentally) 2 weeks, we would then deprecate our support for 5.5 and only support 5.6. Together with nagging mails every few weeks for sites on old versions, that should be doable.

That means till 2024 we have to support (following the Debian release cycle) at least PHP 7.2 while PHP 8.0 is 3 years old and already obsolete.

Nothing says we have to be aligned with any of the Linux distros either. When we jumped from PHP 5.3.1 to 5.3.10 for the minimum we dropped every distro which was a PHP 5.3.3-whatever-42 build. That's not to say they should be ignored either; a lot of organizations have policies to only use the versions in the distro's mainline channels (so with Ubuntu 16.04 only using its "core" PHP 7.0 build and not using a repo to allow other PHP versions). So there is a lot of guessing and balancing involved here, but I don't think we should pin ourselves into a corner and say we're going to support PHP 5.4 as long as RHEL is still under extended support (especially as it can be inferred our number of users on a PHP 5.4 build is under 5% of all 3.8 sites reporting metrics).

So the better plan is to say something like "Your reporting metrics says us we have only x% users with version lower then Y. And we have a reason to drop support, we do it."

It doesn't have to only be "2.5% of users are on our oldest supported PHP branch, that's enough to drop support". But, part of the reason for collecting that data is to have it available to make data driven decisions. In the case of the present 5.3 minimum, how many issues and concerns go away by simply dropping 5.3 support? How much time are we spending to ensure we don't break builds on PHP 5.3 that could be better invested elsewhere? etc. etc.

Thats the reason why I added the "And we have a reason..." part ;-)

Especially with PHP 5.3 we have some security concerns...

What is the benefit of raising the PHP minimum requirement? So we can use PHP features not available in earlier releases? Must we use those features or can we do it with the current versions of PHP? I guess what I am wondering is if PHP 7 support is good enough or must we say that PHP 7.2 is a minimum requirement?

The biggest pain point I see here is that, what was pointed out before, that people may be limited to the release channel of their distro. As for hosting companies, I have the idea that they are doing much better than years ago with supporting new PHP versions and updating is often just to flip the switch to a higher version.

Well, let's take the 3.8.9 release as the practical example.

The core issue that was reported related to the behavior of class_exists() on PHP 5.3. It spun into several "micro" issues directly related to that issue. The entire series of patches were based on a reproducible issue on PHP 5.3 builds, and one of the changes was only really required because of PHP 5.3 support (the others fixed an API validation issue more or less). If 5.3 weren't in our supported stack, it could have essentially been written off as a non-issue. Because it still is in our supported stack, we had to patch an issue affecting a relatively low number of users on a platform that is no longer supported. I'll be kind and say I invested 3-5 hours on that issue myself between security team discussions and actually writing and testing the patches (unrelated to the actual release process). That is time I personally could have spent elsewhere for the benefit of a greater number of people.

In essence, what I'm asking is that we can responsibly say "OK, these versions of PHP are unsupported in general, and our number of users running them are so low that it is no longer in the project's best interests to use its resources to provide support for it, so we are dropping support in x.y+1", instead of forcing us to wait for x+1 as is the case now (of course said decision should be based on more than usage numbers but it's the first quantifiable metric we have available to us so that's what I'm using in examples).

+1 for the minimum requirements change proposed by @mbabker

+1 to make PHP 7.2 the minimum

It would be great to use the features introduced by each PHP version in a meaningful way. Otherwise, we are just limiting the places where the CMS can be installed and raising the requirements without the associated benefits.

There is a lot that can be done with a minimum requirement of PHP 5.6 (constants, traits, closures, use functions / facades, etc).

I would raise it not before 3.10 (or what the last minor would be for 4) to the min requirements J4 has. Till then I would stay where we are.

@laoneo it is only proposed for from 4.0 as stated in the op

@anibalsanchez If the JED didnt repeatedly tell people that J4 would break extensions for things that it wont break it would really help people updating far more than the php version

... as far as I know ... JED is publishing only official links.

It's the manner in which you're communicating. Almost every JED report since 3.8 was released has basically said "Joomla 3.8 broke backward compatibility by renaming a bunch of classes, see the Joomla 4 migration docs for more info".

It is not the link it is the statement that has appeared on every meeting report

"As a consequence of the required changes of Joomla 4, the internal reorganization in the current Joomla 3.8 release is causing issues on extensions that rely on class names like JUser, JMail, JUri, etc. For more information about Joomla 4 and Potential backward compatibility issues."

With a link to a doc that makes no mention of those alleged issues

Ah ok, I'll remove it in the next report.

Thank you - never good to spread un needed FUD - and a report is supposed to be a report of the meeting and not padded out with the contents of the previous reports

I feel that the reports help us to keep the list of open tasks and priorities that we monthly strive to accomplish. Even, if we are outnumbered by the number of tasks at hand, and we have to postpone every time.

Second on the following
+1 for the minimum requirements change proposed by @mbabker
+1 to make PHP 7.2 the minimum

Maybe we should support only a limited number of php versions in the life cycle of J4.

For example, J4.0 would support only 5 versions of php: 7.0, 7.1, 7.2, 7.3 and 7.4. If php 7.5 will be released then joomla will drop support for 7.0 in the next 4.(x+1) release.

[Only as an example]

From above idea, J3.8 should support only php 5.5 ... 7.2.
If php 7.3 will be released before the J3.9 release, then php 5.5 will be deprecated in J3.9 and support will be dropped in J3.10.
J3.10 will support only 5.6 .. 7.3.

The disadvantage is that Joomla will depend on the php releases.

is not only about on PHP, imo is much more about on PHP adoption by hosting providers and much more about main distro adoption, just not to mention about db's versions&type adoption... (oops redis) ...

Having an automated minimum release based on PHP release cycles doesn't make sense to me.
If there is no strong technical reason to raise the minimum, we shouldn't raise it. But we should be able to raise the requirements in case of strong technical reasons.
From memory within J3, we wanted to support stronger password encryption which we could only do (while still keeping our sanity) by raising PHP requirements to 5.3.10 (from previously 5.3.3 I think).
There may be similar cases in future and we should allow ourselfs to raise the requirements for such cases where breaking B/C is justified by what we gain (while keeping impact as low as reasonable).

If there is no strong technical reason to raise the minimum, we shouldn't raise it.

The human factor is also important. At least I like to write code in a newer version.

Support for 3 years after the last php x.y release - EOL can also be considered.

See http://php.net/supported-versions.php

This would mean that in September 2018, Joomla 3.10 could drop support for php <= 5.4.

Sticking to the minimal php version (5.3.10) until the next major release, absorbs human resources and stops product development.

Having an automated minimum release based on PHP release cycles doesn't make sense to me.
If there is no strong technical reason to raise the minimum, we shouldn't raise it. But we should be able to raise the requirements in case of strong technical reasons.

There is no technical reason to raise the PHP minimum for Joomla 4. Everything we need is available to us on a PHP 5.3 build with polyfills (the only true newer feature we depend on is the PHP 5.5 password hashing API, polyfilled down to PHP 5.2.4; I can't think of anything we have a hard dependency to that if there weren't a polyfill we would have issues working around). There are a lot of non technical reasons why supporting PHP 5.3 is becoming more of a burden than a benefit.

We're not talking about the major J4.0.0 release here, right? We're talking about the successive J4.x minor and patch releases. The topic is also not the J3 series like some implicate as far as I understood.

Of course it's fine for J4.0.0 to drop support for all PHP5.x releases and even older PHP7 releases. That is already possible with the existing strategy and is also already decision. But that's not the topic here as far as I understood it.

I was just responding to your "we should only raise if there's a technical reason" comment. Fact of the matter is that since 2012 there has been exactly one technical need and that was to be able to reliably use bcrypt hashing, since then there have been none and the odds of one being introduced into PHP are very low. So if the argument is "there should be a technical need first", then that milestone will never be reached.

It also depends on the definition of what is a "technical need" for the project.

The current code base has been developed for PHP 5.3. So, it is confined to 5.3 or superior, per definition.

On the other hand, Symfony 4.0 and Laravel 5.6 both require PHP 7.1.3 or higher (and they won't run on previous versions) due to the features they use.

@mbabker your definition is less technical then "required to write code", my definition is more "would we like to use this new feature because we have a big benefit of it".

For example typed variables or properties which may increase performance with the planned JIT.

But each of this version requirements would anyway need its own discussion.

The other problem are our dependency as anibal mentioned, for example jquery (not PHP i know) we couldn't update but have a "security" issue with the current version.
I don't know the policy for each library we use, maybe this could also lead to a version upgrade?

For example typed variables or properties which may increase performance with the planned JIT.

I don't know the implementation of typed properties yet (seen the RFC, haven't code reviewed), but with scalar typehinting and return typing those are B/C breaks without a PHP 7.2 minimum because of the parameter widening and type covariance/contravariance support added in that release. So even if there are nice to have features in the pipeline (and I personally favor strict typing over duck typing), it's not something that is an absolute need (in the case of typing you can do every check that typehinting gives in your function/method) and in some cases these new features force API B/C breaks anyway which would mean we'd have to punt implementations to the next major version anyway.

Third party libraries have to be handled on a case-by-case basis. jQuery, Bootstrap, and PHPMailer are a de facto part of our public API and a major version bump of those wouldn't be acceptable (even if they retained the same support we have for our client/server environments; jQuery and TinyMCE at a minimum can't upgrade because of the lack of IE8 support in current versions, PHPMailer or newer majors of Symfony because of raised PHP minimums). Something like Symfony's YAML component isn't really part of our public API but is included in our package as it has integrations into our Registry package, in theory if it weren't for the raised PHP minimum that could be upgraded from 2.8 to 3.4 in a 3.x release without major issue from our end (but then you get into a debate over whether a packaged dependency in a distributed application also has to play by the same B/C rules as your own application's API, with PHPMailer it's an absolute yes as long as we have Joomla\CMS\Mail\Mail extends \PHPMailer).

Can we sum this up that we support the original RFC? I would propose the following wording:

6.4 Minimum technical requirements

The minimum technical requirements, such as PHP version, database version, etc., can should only be increased for the first release of a new major version. The project reserves the right to increase the minimum requirements when there are good reasons to do so. (For example security issues in older PHP versions or breaking regressions in a MySQL release.)

Feel free to improve the wording, but whatever we do, we should come to a conclusion here.

I would add one sentence, something like this.

Minimum requirements can be increased when the software version is 3 years after EOL and we have a big benefit of it and if available, less than 3% of all sites contain reporting data in this version.

@csthomas Why would you limit yourself like that? Joomla 3.2 was released November 2013 and had a huge issue with the password encryption because of PHP 5.3. PHP 5.3 wasn't EOL until August 2014. So if we would stick with your requirements that we can only change requirements 3 years after EOL, we wouldn't have solved anything of the issues that started this RFC.

We are not creating rules against evil advisaries here, but for ourselfs. We are describing our intentions to interested people who consider using Joomla. They are not interested in reading "War and Peace" on how we wrap ourselfs in a strict corsett of rules, but what our intentions are and those are pretty clear:

We will set some requirements and stick to those for the series of a major release cycle, except when there are good reasons not to.

Nobody is going to simply raise the requirements for 3.9 to PHP 7 or something similar. First of all, we are all friends here and (I hope) no one is here to kill this project. But even if that was the case, we do have several guards against such changes in the codebase. CI, 2-Tester-principel, merging only by trusted maintainers. Every change in requirements will be precluded with an awfully long discussion.

What I'm trying to say here: Keep it short and reasonable, keep it a little bit vague, too, so that we have some wiggle room. Or do you really want to limit changes to requirements only to PHP version which are 3 years EOL on a full moon with NASDAQ having fallen 10% in a day? Then we don't have to do this change at all.

My main intention is to remove old things (php 5.3, postgresql 8.3, ...). I set 3 years because I looked at it from today's perspective - it was my fault.

@Hackwar Then you can remove the condition with the end of life.

Joomla 3.2 was released November 2013 and had a huge issue with the password encryption because of PHP 5.3. PHP 5.3 wasn't EOL until August 2014.

Then it would be "a big benefit of it" but still problem not less than 3%.

Today we could remove support for php 5.3 (3 years after EOL)
and postgresql 8.3 or even higher.

First short version:

Minimum requirements can be increased when we have a big benefit of it.

Long version:

Minimum requirements can be increased when we have a big benefit of it OR if available, less than 3% of all sites, contain reporting data in this version.

If this is still wrong or too many words, then I will wait for other propositions.

"Big benefit" is too vague. As I've already pointed out, as a project we honestly have very little need to move beyond the PHP 5.3 feature set; almost everything in newer versions is syntactic sugar and the few functions we truly rely on are all polyfilled.

Locking to a hard "we can only do this three years after EOL" is kind of against the aim here. It's not intended to set a timeframe into the strategy, just a high level "if there is a strong enough argument to justify change, we can do this without incrementing the major version number". All data at the time of said discussion/decision would be taken into account.

👍 for PHP 7.2 for Joomla 4. Strongly.
People with a PHP 5.6-7.1 host can stay on Joomla 3.10 for 2 years after Joomla 4 release.

@mbabker has listed here very valid and powerful benefits for Joomla to move minimum up, and 7.2 brings the maximum benefits: #18562 (comment)

Also suggesting to raison MySQL minimum requirement for Joomla 4 to MySQL 5.7.8:

MySQL 5.7.8 introduces a wonderful new feature that Joomla could make good use of: JSON column types with indexing for fast selects::
https://dev.mysql.com/doc/refman/5.7/en/json.html

I remembered one more thing.

If contributor or automated tests can not test Joomla on the old software for the last year, it means that such support is zero and should be removed. An example is PostgreSQL 8.3 where you can not install joomla 3.

However we are not discussing here what the minimum requirements should be, but if we can change the requirements after the release of a major version. And we are also not talking about raising requirements because "new is oh-so-cool". We are talking about raising the minimum requirements because we are forced to update our password hashing and the PHP version that we supported has/had a breaking bug in the encryption implementation, either forcing users to use unsecure hashing or breaking their site.

So far we agreed that we want to be able to change requirements. Now we are discussing how limited we want to do that and how verbose we want to formulate that in our development strategy.

So, here again my proposal

6.4 Minimum technical requirements

The minimum technical requirements, such as PHP version, database version, etc., can should only be increased for the first release of a new major version. The project reserves the right to increase the minimum requirements when there are good reasons to do so. (For example security issues in older PHP versions or breaking regressions in a MySQL release.)

As I wrote before, we should make our intentions clear (we only want to change the requirements for the first release of a new major version) but keep it vague enough as to not lock us into overly strict rules. Keep in mind that we are writing this for us and not as a law for evil adversaries. It is fine if we have loopholes, since we are not interested in exploiting those.

Text makes sense to me.

Then OK.

Can we expect any real changes in the code, or joomla will change only point 6.4.

As was written in the original RFC, this is aimed at 4.0. But regardless of the original RFC: What would you expect now to happen? Would there be a good reason to change the minimum requirements for 3.x now? I mean a real reason, not just "PHP5.3 is so 2012". And for 4.0 we are still open to raise the requirements to whatever we want.

I would expect to raise PostgreSQL to 9.0 (or at least to 8.4) for J3.

Then it would be true that joomla real support minimal requirement version.
Also then we can remove a workaround for ROW_NUMBER to support Postgresql 8.3.

The biggest valid objection to raising PHP version requirements is the one voiced at the top of this thread by @HLeithner, where site owners find themselves unable to upgrade PHP due to version constraints of their host operating system.

This is a very valid point and has historically been a strong factor in many applications choosing to hold back their adoption of newer PHP versions.

However, I believe it is diminishing as an argument, and will become largely irrelevant in years to come due to the rise of Docker.

Last year, in order to host a new Joomla site, I had to set up a dedicated server to host it on. That server ran an OS and PHP version which I may not have had a choice over.

This year, to do the same thing, I am creating a Dockerized environment where I can decide exactly what components make up the platform, and without having to make any consideration to the host OS.

The Dockerised environment is more flexible, more stable, more maintainable and more supportable than the server-based environment.

I know that I will never be hosting a new site on a dedicated server or VM again.

Others may take longer to get to the point that I have, but Docker has only been in existence for a few years now and it's already turning things around in a big way. I believe that it will only take a few more years and everyone will be using it. The days of people worrying about whether their CMS is compatible with their old PHP version are going to disappear very quickly. In the future, it will become very easy to increase Joomla's version requirements.

Ok, so there is no objection to the proposal above from 3 days ago. Can we simply add this to the Dev strategy or do you want to discuss this again in the PLT or something?

Sorry for pushing this like this, but it feels as if this is slowly devolving into an endless discussion that will eventually simply taper out without a decision. Since no one objected the basic idea of this RFC, maybe we can simply go ahead now?

Is this something that should now be taken to the Production Department for a decision.

Closing due to lack of response.