Welcome Guest, Not a member yet? Register   Sign In
When do we drop PHP 8.0 support?
#11

(03-09-2023, 07:03 AM)elementcode Wrote:
(03-09-2023, 01:02 AM)superior Wrote: But I can imagine there are packages who rely on 8.0 from previous releases within CI4 projects.
Those can still use the 4.3 Branch.

(03-09-2023, 02:42 AM)tgix Wrote: [...] maybe it's time to move to CI 5.0 with PHP 8.1+ as supported version. This would keep version 4 for backward compatibility and serious bug-fixes.
Since CI handles its breaking changes at the minor, the CI 4.3 branch could easily be used for backward compatibility and serious bug-fixes.
CI major versions seem to be reserved for major framework upgrades (see CI3 vs CI4)

In my opinion, we should drop all but the current PHP version (8.2) for every new minor branch, since those new minor branches always mean breaking changes.
This would allow us to go forward with the pace of PHP and not limp behind trying to support deprecated PHP versions.

People who can't upgrade to a new PHP Version could still use all upgrades in their respective minor branch.
If they need features from a higher minor branch they need to upgrade their PHP version.
This seems to be a fair deal to me.

When CI requires 8.2, and for example DomPdf supports untill 8.1 you'll run with problems.
Reply
#12

(This post was last modified: 03-09-2023, 07:57 PM by iRedds.)

(03-09-2023, 03:38 AM)kenjis Wrote: https://packagist.org/packages/codeignit.../php-stats

1. It seems to me that this is not relevant data.
This graph shows package installations. That is, if I install the package ten times through the composer, and then delete it, it will count as ten installations, and not one in fact.
Since CI supports several PHP versions, you can change the version without reinstalling the framework.

2. There are no statistics on the use of the zip installation.

It makes no sense to abandon only php 8.0, leaving php 7.4.
And according to the given statistics, then 7.4 + 8.0 = 43% (for 4.3.*)
Reply
#13

@iRedds Of course it is not accurate, but relevant.
If you can provide better statistics, please do so.

We can see this. In this statistics 7.4 + 8.0 = 40%
https://packagist.org/php-statistics

Then, as you can see from reading the GitHub Issue, the proposal is to drop supporting 8.0 even if there are many users.
And dropping PHP 8.0 means dropping 7.4 and 8.0.
Reply
#14

(03-09-2023, 07:18 AM)superior Wrote: When CI requires 8.2, and for example DomPdf supports untill 8.1 you'll run with problems.

Yes, this problem may happen a lot. So I don't agree with dropping all PHP versions except the latest (PHP 8.2 now).

We haven't heard many opinions yet, but so far we haven't heard anyone opposes dropping 8.0.
If you do, please tell us why.
Reply
#15

(03-09-2023, 07:03 AM)elementcode Wrote: Since CI handles its breaking changes at the minor, the CI 4.3 branch could easily be used for backward compatibility and serious bug-fixes.
CI major versions seem to be reserved for major framework upgrades (see CI3 vs CI4)

In my opinion, we should drop all but the current PHP version (8.2) for every new minor branch, since those new minor branches always mean breaking changes.
This would allow us to go forward with the pace of PHP and not limp behind trying to support deprecated PHP versions.

People who can't upgrade to a new PHP Version could still use all upgrades in their respective minor branch.
If they need features from a higher minor branch they need to upgrade their PHP version.
This seems to be a fair deal to me.

We maintain only one minor version at a time.
Once v4.4.0 is released, no bug fixes for v4.3 won't be released.
This is because we have no resource to maintain more than one branch.
(And technically the current release process cannot release two minor versions.)

So people who can't upgrade cannot get a security fix if a vulnerability is found.
This is a serious issue.
Reply
#16

What do other members of the CI team think about it?
Reply
#17

(This post was last modified: 03-20-2023, 01:16 AM by elementcode.)

(03-11-2023, 05:29 AM)kenjis Wrote: So people who can't upgrade cannot get a security fix if a vulnerability is found.
This is a serious issue.

Under the assumption that CI 4.4 won't release until end of this year (which seems realistic to me):
People who can't upgrade run their CI with a vulnerability because they run an outdated and unmaintained PHP Version, which itself receives no vulnerability fixes.
Not sure about how serious of an argument against going forward that is..


Parallel to 4.4 we might be able to change the release chain to work with multiple minor branches, so future minors are not held back because of that.
It's fully understandable that anyway no bug fixes will be released because of the lacking resources, but we could release security patches at least.
Reply
#18

See https://github.com/codeigniter4/framework/branches
The framework repository has only master.

The release process is complex with some repositories and optimized for one branch.
Read deploy-* github workflows:
https://github.com/codeigniter4/CodeIgni.../workflows

It is a really big work to change it.
Reply
#19

while we are thinking whether to abandon 7.4 and 8.0, version 8.1 will be removed from support =)
Reply
#20

(06-18-2023, 10:07 PM)iRedds Wrote: while we are thinking whether to abandon 7.4 and 8.0, version 8.1 will be removed from support =)

What do you mean? 8.1 will be supported until Nov 24, 2024 - https://www.php.net/supported-versions.php
Reply




Theme © iAndrew 2016 - Forum software by © MyBB