[RFC]: Plans for a possible new major release 4.0

[tux-rampage]

RFC

Q	A
Proposed Version(s)	4.0.0
BC Break?	Yes

Goal

The goal is to address open issues as well as to improve the maintainability of this library.

Background

Currently this component uses array's for configuration throughout the entire library which makes typesafety and static analysis harder to maintain. Also it still has code necessary for PHP 7 which is EOL for quite a while now.

Considerations

All features should ideally be introduced into the current stable version 3.x in a backwards compatible way.
This will provide users a clear transition path that can already be done when running version 3.x.

Proposal(s)

1. Old functionality and future breaking points must be marked accordingly:

   • Deprecations with @deprecated
   • Portected methods and properties that should become private with @private or @internal
   • Classes that will become final with @final

   All annotated changes in 3.x will then be applied in 4.0.0

2. Doc-type type hints will be replaced or extended with native type hints. No method or property should be untyped (mixed will be used when necessary to explicitly state the intent of any type or psalm templates).

3. Array-Configuration will only be used as input. Within the library all Configuration should be kept in strongly typed and well defined Value-Objects.

4. The AoT Compiler should be moved from this code base into a separate package/repository to allow adding it as a dev-dependency, since it is not required for runtime purposes.

5. Version 4.0.0 should drop support for all PHP versions prior 8.2 (not 8.3 as previously suggested)

Appendix

As for the process I'd start PRs against the 3.x branch (3.15.x at the time of writing this). When the current 3.x reached a state for the transition, I'd create a 4.0.x branch, a 4.0.0 milestone and start pull requests for the Deprecation removals, type changes and php version bumps.

[gsteel]

We discussed this at the TSC meet on 2nd December. The only point raised was dropping support for 8.2 in v4 without any clear argument as to why.

General consensus is we support all currently maintained versions of PHP unless there's a compelling reason to drop a version that is still receiving security patches which is Dec 2026 for 8.2. Totally behind dropping support for 8.1 for readonly props.

What is the reason for dropping 8.2?

[tux-rampage]

What is the reason for dropping 8.2?

No hard reason, just for embracing new PHP features such as #[\Override]. But since this is an Attribute it can be used even in lower PHP-Versions. It might be possible to add a shim for these attributes so that they can be used without breaking Reflection-API usage and to satisfy Static-Analysis-Tools.

So I'm fine with keeping 8.2.

[mlussi90]

Are there any plans to release a new major version including the compatibility so servicemanager 4.0?

At the moment i'm blocked with upgrading my project to the newest laminas packages because of the dependency to laminas-di.

If there are any contributions needed, please let me know

[tux-rampage]

Are there any plans to release a new major version including the compatibility so servicemanager 4.0?

At the moment i'm blocked with upgrading my project to the newest laminas packages because of the dependency to laminas-di.

If there are any contributions needed, please let me know

Yes. The affected class will become final in the next release. Maybe we'll find a dynamic backport a dynamic version for 3.x