Drop PHP 7.4 support

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%

[kenjis]

Description
See #6921

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Next: apply Rector to update syntax and property promotion 👍

Note: UnionTypesRector may need to be skipped to avoid BC break

[kenjis]

@samsonasik I'm working on it.

Can we use property promotion? Isn't it a breaking change?

[samsonasik]

Yes, Rector apply only on private property or protected property on final class which doesn't override parent by default.

[samsonasik]

Just verify, public property in constructor promotion is also fine 👍 , see https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/fixture.php.inc#L30

[samsonasik]

BC break handling already covered,
https://github.com/rectorphp/rector-src/blob/2b35d2e75ea03ffe643c012485952ec6df3ea2ba/rules-tests/Php80/Rector/Class_/ClassPropertyAssignToConstructorPromotionRector/Fixture/skip_parent_public.php.inc#L10

except we have special conditon, we may need to skip

[kenjis]

It seems using property promotion is okay.
https://3v4l.org/MnFQD

[michalsn]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

[samsonasik]

@michalsn I think yes, that can wait until 4.4. The related PRs to it are for testing functionality and possible BC break.

[datamweb]

PHP 7.4 still has almost ~30% usage according to stats: https://packagist.org/php-statistics

Isn't it a bit early to cut off such a volume of users? Maybe it's better to announce such a change for v4.4.

I agree with this. Even an important part of shield users use 7.4.
Also, many hosting companies are just now offering version 8.0, in many companies 8.1 is not yet available, at least in my country.

[kenjis]

It is true that there are still many.
https://packagist.org/packages/codeigniter4/framework/php-stats
7.4 35.7%

[MGatner]

We definitely need 4.3 to be 7.4 compatible. It has lots and lots of changes and improvements, and if we're going to have a portion of the population lagging behind 8.x I would rather they are on a more compatible version.

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

[MGatner]

I think we only need one 8.x check - we can probably drop this matrix altogether.

[kenjis]

Done.

[MGatner]

Same here: Rector doesn't really care about its native version; running in 7.4 was just a safety.

[kenjis]

Done.

[michalsn]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

We would end up maintaining two versions. Any fixes would have to go to both versions - it sounds like a little nightmare to me.

Ideally, we could announce something with the release of v4.3 - that the dropping of PHP 7.4 is coming in 4.4 or 4.5 - but I feel like the final call on this should be based on usage statistics.

[kenjis]

The current Git flow only allows releases from master, so I guess we can't successfully release two versions at the same time. Releasing 4.4.0 after 4.3.0 would make master 4.4, but releasing 4.3.1 after that would require master to be 4.3 (at that time develop).

[kenjis]

Maybe we release 4.3 and 4.4 together - the latter dropping support for 7.4 and making any internal upgrades (via Rector and CS Fixer) that we can.

I am not sure what the point is of releasing 4.4 at the same time.
4.4 is the next version. Once we released it, we cannot add any enhancement to it.
We will need 4.5 branch for development.

[MGatner]

We are dropping 7.4 support. We can revisit that conversation if we need to, but our decision was that we don't have enough community contributors and maintainer time to support multiple release branches. I was suggesting that we release 4.3 as >=7.4 so all the work we've already done is still available to people stuck on 7; then, immediately after we apply >=8.0. We don't have to release that, but from that point on support for 7 would be gone.

[kenjis]

The current PHP 7.4 share is too large compared to when 7.3 was dropped.

I suggest that we actively announce that we will drop 7.4 in the next 4.4.

[tangix]

Just my thoughts:
I think you are overly aggressive in ditching 7.4 a week after EOL. As I put on the forums; keep CI 4.x with current PHP support and aim for CI 5 targeting PHP 8.1 as minimum. We jumped most projects 7.4 -> 8.1 but some 7.4 projects are lingering due to the changes of null-handling in str*() functions.
As shown, 8.0 was a good release but it doesn't seem to get traction and will be EOL in 11 months.

[MGatner]

Thanks for the feedback @tangix. We've been back and forth on this a lot, but one reason we decided to push for >=8.0 now was to alleviate the upgrade path to v5. It's also in keeping with our policy of only supporting secure versions of PHP; I'm fine with some lingering overlap of 7.4 but committing to it for another year is committing us to an extra layer of responsibility from a language without security patches.

[kenjis]

Yes, PHP 7.4 is no longer supported and all users hold the security risk already.

In summary, it would be something like this:

• v4.3.x will support PHP 7.4. v4.3.0 will be released soon. The current 4.3 branch will be develop branch.
• The next 4.4 branch will drop PHP 7.4. And I'm not sure but I guess v4.4.0 will be released about 6 month later.

[kenjis]

https://packagist.org/packages/codeigniter4/framework/php-stats
PHP 7.4: 29.7%