Do you need very strict Backwork Comapibility that prevents CI4 development?

I would like to loosen the current Backward Compatibility policy.
Because the disadvantages of the policy seem to outweigh the benefits.
- if we keep the strict rule and we wait for v5, it takes too much time (v5 does not seem to come in a year or so).
- the current strict rule is preventing contributors/maintainers contributions (many developers wants to work with cleaner code).
- if we keep the strict rule, we might lose contributions.
- in the first place, CI4 does not have a stable enough APIs to guarantee Backward Compatibility. (Following SemVer is impossible, or we must count up major version every time when the release includes breaking changes.)
- nobody seems to want the strict Backward Compatibility policy. It seems many users accept minor changes with clear documentations.

If we loosen the rule, we can fix many *incorrect* method signatures, and can add missing type hints. (CI4's type coverage is very low.)

The new rule is:
- We can change method signature with minor version up, unless these changes do not break the normal users existing apps.
- What is the normal users existing apps:
  - apps which uses public methods (not having @internal) of CI4
  - do not extends CI4 classes
  - do not purposely specify the default value like null in the method calls

And if we accept the new rule the following PR is acceptable in v4.2.0:
https://github.com/codeigniter4/CodeIgniter4/pull/5509

---

One last thought… Semver has a bit of an unusual definition for “bug fix”:
>  A bug fix is defined as an internal change that fixes incorrect behavior.
I got to CI4 after most of the initial code was written. I stand on the backs of developers who volunteered lots of hard work and many hours to write that code - most of whom are not around anymore. In my opinion, there is a fair amount of “incorrect behavior” in the way things were originally written (not faulting anyone, we all have our weaknesses). So I ponder this question myself and invite you to as well:
Can we modify intentional behavior that we disagree with and release it as a bug fix?

A bug fix can be included in a patch release.
I think it is safer that method signature changes are not included in a patch release.

> Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.
https://semver.org/#spec-item-1

If we follow SemVer, the first thing is to declare a public API.
How about like this?

The public API is all public methods and functions in the framework that are documented in the User Guide and not having @internal in the doc comments.
And we consider all the methods as *final*, even if it is not declared with the final keyword.
And we do not guarantee the default values of the parameters are not changed.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper