refactor: drop support for Config\App::$proxyIPs = ''

[kenjis]

Needs #7620

Description

• remove Request::$proxyIPs
• drop support for Config\App::$proxyIPs = '' (old Config file)

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

[michalsn]

Any context? We have a lot of code marked as deprecated. Why are we removing this exact thing now? Are we going to remove more on the way to 4.4?

[datamweb]

We have a lot of code marked as deprecated.

I believe it would be a good guide for developers if the exact deprecation version is provided. In addition, the accumulation of notifications is prevented.

@deprecated [<Semantic Version>] [<description>]

more info here.

[kenjis]

Oh, removing Request::$proxyIPs is a breaking change?

[kenjis]

@michalsn Reverted Request::$proxyIPs.
When a dev extends Request and use $proxyIPs in it, and if we remove it, the extended Request would break.

Are we going to remove more on the way to 4.4?

I would like to remove deprecated properties in app/Config/*.

[michalsn]

When it comes to removing deprecated config variables (and code in general), it would be great if we could announce such changes one version ahead of doing this. But if others have nothing against then I'm fine with removing these in 4.4.

It would be nice if we could add a date for removing deprecated code when we mark it as deprecated. For example, if we deprecate something in the 4.4.0 release, the description would say that it will be removed in 4.6.0. This would be more transparent and show developers how much time they have to make permanent changes.

Honestly, I see no issue with removing Request::$proxyIPs. We don't use it anymore internally, so if someone use it in it's own version of the class it will become public property in the worst-case scenario (with no proper declaration). Or am I missing something?

[kenjis]

Honestly, I see no issue with removing Request::$proxyIPs. We don't use it anymore internally, so if someone use it in it's own version of the class it will become public property in the worst-case scenario (with no proper declaration). Or am I missing something?

Dynamic properties cause errors in PHP 8.2.

[kenjis]

If we don't mind removing the deprecated items other than Config items, I want to remove them after changing the Backward Compatibility Notes.

It would be nice to give notice of the removal in one previous version, but it would be a hassle for us to do so.

If we set a rule that we will remove deprecated items in the next next version, I think it would be easier to do so.

[michalsn]

BC notes seem a bit outdated.

If we set a rule that we will remove deprecated items in the next next version, I think it would be easier to do so.

Sounds good.