Realign Yii 2.0.x version lifecycle with changed PHP release cycle

[rhertogh]

The Yii 2.0.x version lifecycle was aligned with the supported PHP versions release cycle.

Recently the PHP RFC to update the PHP release cycle has passed, two of those changes have impact on this alignment:

1. Extend Security Support by One Year
2. Extend Releases Cycle to End of Year

If we decide to realign the Yii 2.0.x version lifecycle it would look as follows:

Yii2 Version	PHP version	Development status	EOL ¹
<= 2.0.49.*	>= 5.4, <= 8.3	security fixes only	31 Dec 2027 ³
>= 2.0.50	>= 7.3, <= 8.4	bug fixes and security fixes only	bugfixes till 31 Dec 2027 ³, security fixes till 31 Dec 2028 ⁴
>= 2.2.0 ²	>= 8.1	active development

¹ All mentioned dates may be subject to change and no rights can be derived from them.
² Note: Yii 2.1 was skipped, Yii 2.2 has not yet been released.
³ PHP 8.3 EOL date.
⁴ Expected PHP 8.4 EOL date.

[rhertogh]

@samdark @bizley @terabytesoftw @rob006 @mtangoo @schmunk42 and other @yiisoft/core-developers your thoughts on this?

[samdark]

The Yii2 version lifecycle was aligned with the supported PHP versions release cycle.

That's not correct. Yii2 release cycle was never aligned with PHP one. It was "5 years since next major framework release" i.e. Yii2 is meant to be supported for 5 years after Yii3 is officially released. We were always supporting very dated versions of PHP. It's changing now with Yii3 and Yii2.2.

[rhertogh]

@samdark I have indeed formulated it too broadly. It's aimed at the EOL dates for the 2.0.x versions. Footnotes 3 and 4 point to the EOL dates of their respective PHP version EOL date. In that regard the Yii 2.0.x versions EOL dates were "aligned" with their supported PHP versions.

I've updated the title and text to reflect this insight.

[terabytesoftw]

What do you think about upgrading to at least 7.4? That will give us some improvements to the code and even more well-maintained PHP extensions.

@rob006 @rhertogh @bizley @mtangoo @samdark @max-s-lab @schmunk42

[max-s-lab]

I think that would be great 👍

[rob006]

That will give us some improvements to the code and even more well-maintained PHP extensions.

Any examples?

[terabytesoftw]

That will give us some improvements to the code and even more well-maintained PHP extensions.

Any examples?

While it is technically easier to keep the master branch and the 2.2 branch synchronized with the new improvements, many critical development tools have dropped PHP 7.3 support. The best example being PHPStan 2.0 which only supports PHP 7.4+, but this extends to PHP-CS-Fixer 3.x, and numerous Composer packages.

Many extensions are causing CI issues on 7.3, and maintaining compatibility increasingly requires workarounds that add technical debt.

This upgrade positions us better for the inevitable migration to PHP 8.0/8.1 while improving the developer experience for contributors.

Given that PHP 7.3 reached EOL in December 2022, supporting 7.4 as the minimum provides a more stable foundation without sacrificing real world usage, as most production environments have already moved beyond 7.3.

We could simplify a lot of code without doing BC.

[bizley]

I'm all for 7.4 as minimum.

[xicond]

but IMHO, we still need to maintain unit test for 7.3 as we just change PATCH version 2.0.x
so in the future or next after next PATCH we shouldnt break BC 7.3
just improving phpcs, phpstan, psalm (static analysis) which not effecting BC to 7.3 directly