Image Bundle Laravel Package

Product Decisions This Supports

• Platform baseline decision: 6.0.0 requires PHP 8.1+ and Symfony 6, so it acts as a forcing function for the product’s PHP/Laravel/Symfony upgrade timeline. PMs can use it to decide whether to standardize on PHP 8.1 now or pin the package to 5.x.
• Laravel/Symfony support matrix: Dropping Symfony 4 and adding Symfony 6 compatibility narrows supported stacks. This informs which Laravel versions the product can claim to support and when to retire legacy branches.
• Dependency modernization / build-vs-buy: If the package is central to the product, upgrading is likely cheaper than forking or replacing it. If the product must remain on PHP 8.0 or Symfony 4/5, PMs should explicitly choose between maintaining a fork, pinning an older major, or selecting an alternative.
• Roadmap and release planning: The [BC] PHP 8.1 type changes mean this is not a routine minor upgrade. Plan migration work for custom extensions, interface implementations, and test coverage before adopting.
• Risk and support policy: Staying on an older major after Symfony 4 support is dropped creates security/maintenance risk. PMs should budget upgrade work or document accepted risk.
• Use-case fit: Best suited to new or actively modernized Laravel applications on PHP 8.1+ and Symfony 6-compatible dependencies; less suitable for legacy products with long support tails.

When to Consider This Package

Consider 6.0.0 when:

• The application is on PHP 8.1+ and can adopt Symfony 6-compatible dependencies.
• The product is on, or moving to, a Laravel version aligned with Symfony 6.
• You need a maintained package version with modern PHP type safety and current framework compatibility.
• You can absorb a major-version BC break, including changes to public types/signatures that may affect custom subclasses or implementations.
• You are starting a greenfield Laravel project and want to avoid adopting a dependency already behind the current platform baseline.

Look elsewhere or delay when:

• The product must support PHP 8.0 or lower, Symfony 4/5, or older Laravel versions.
• You rely heavily on extending package classes or implementing its interfaces and cannot refactor typed signatures soon.
• You need a long-term-support dependency for a legacy branch and cannot maintain a fork.
• An alternative package offers broader PHP/Symfony compatibility with acceptable trade-offs.
• The upgrade cannot be scheduled alongside platform modernization and regression testing.

How to Pitch It (Stakeholders)

Executives: This is a major release that keeps the package aligned with supported PHP and Symfony versions. It reduces long-term maintenance and security risk, but it requires a platform upgrade to PHP 8.1+ and planned engineering effort. It should be treated as modernization work, not a drop-in feature update.

Engineering: Expect breaking changes: PHP 8.1 is required, Symfony 4 is dropped, Symfony 6 is supported, and PHP 8.1 types/signatures may break custom extensions. Audit Composer constraints, run the test suite on PHP 8.1/Symfony 6, update subclass/interface code, and pin to 5.x until the platform upgrade is complete.

Product/Support: Use this release to set the supported-version policy and communicate upgrade timing. Avoid coupling the migration to a customer-facing release unless the platform upgrade is already funded and tested; otherwise, keep the older major pinned and document the support risk.