[RFC]: PSR compatibility via dedicated satellites

[boesing]

RFC

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

Goal

Provide dedicated PSR decorator satellites so we can earlier react on interface changes in PSR versions.

Background

Currently, we only support v1 of both psr/cache and psr/simple-cache. To provide support for v2 and v3, of these components, we would need major releases of laminas-cache. This should be avoided as laminas-cache mostly does not need a major bump just to provide support for new versions of the PSR interfaces.

With a dedicated satellite, e.g. laminas/laminas-cache-psr, it would be easier to create major releases to adapt interface changes while keeping overall maintenance for upstream projects low.

Considerations

Considering the fact, that upstream projects only have to bump the PSR satellite, upgrading would be more straig-forward than a major update of laminas-cache.

Proposal(s)

I would propose a dedicated laminas/laminas-cache-psr package which extracts everything from the Laminas\Cache\Psr namespace to a dedicated package. By doing so, we can keep BC compatibility in v3 of laminas-cache while moving that satellite to suggest in v4. Starting with v4, every upstream project have to require laminas/laminas-cache-psr if they need PSR-6 or PSR-16 decorator.

As of now (2021-11-22), both packages (psr/cache and psr/simple-cache) do have v1.0, v2.0 and v3.0 releases. This would enable us to create v1.0, v2.0 and v3.0 releases for the laminas/laminas-cache-psr

Appendix

There are some problems when going this way. In the next years, laminas-cache might evolve. This would have effects on the StorageInterface and maybe other interfaces which are currently consumed by the decorators.

At some point, it might be necessary to create new major versions of the satellites in order to match laminas-cache requirements. At this point, major versions might derive from those of the PSR standards.

• Are there best practices to avoid this kind of problem?
• Is it "smart" decouple laminas-cache this way form the PSR interfaces while having a dependency on laminas-cache itself?
• There is #133 which wants to support v1 & v3 via class_alias. This would enable us to provide support for multiple PSR versions by using class_alias. I would prefer dedicated satellites instead but if the feedback in this RFC would be to tackle multi version support for the PSR interfaces, we can focus on that approach.