Allinkl Bundle Laravel Package

Product Decisions This Supports

• Maintenance and platform policy, not product feature delivery. Release 1.8.0 contains dependency and tooling updates only: PHPUnit 12, PHPStan 2, Symfony DI test v6, removal of Infection and Psalm, CI/tool config cleanup, and dropping PHP 8.2. There are no new user-facing features, API additions, or documented bug fixes.
• Runtime floor decision: Dropping PHP 8.2 makes this a breaking change for teams still on PHP 8.2, despite the minor version number. Product and engineering should treat PHP 8.3+ as an adoption prerequisite for this release.
• Build vs. buy for hosting-provider integration: If the roadmap requires All-Inkl-specific integration, this package can reduce custom integration work. If the need is generic hosting abstraction, a provider-agnostic client or thin in-house adapter may be a better fit.
• Dependency governance: The release signals active maintenance and modernization of the test/static-analysis stack, but it is housekeeping. It should not be used to justify roadmap commitments or customer-facing announcements.
• Quality-gate tradeoff: Consolidating on PHPStan and removing Psalm is reasonable tooling standardization. Removing Infection testing reduces mutation-testing coverage in the package’s own pipeline; teams that rely on mutation testing as a vendor quality signal should account for that at the application level.
• Framework-fit decision: This is a Symfony bundle by naming and ecosystem. For a Laravel-first product, confirm there is a viable integration path before treating it as a Laravel package. The release notes provide no evidence of Laravel-specific support or changes.

When to Consider This Package

Consider it when:

• The product genuinely needs All-Inkl-specific integration and the team wants to avoid building that connector from scratch.
• The application is on PHP 8.3 or newer, or can upgrade before adopting 1.8.0.
• The team is comfortable with a maintenance-oriented dependency and does not require new feature velocity from this package.
• The integration can be isolated behind an internal interface, so the package can be replaced later if maintenance slows.
• Engineering can validate framework compatibility, Composer constraints, and transitive dependency changes in CI.

Look elsewhere or defer when:

• The product must remain on PHP 8.2 or earlier.
• The product is Laravel-native and cannot absorb a Symfony bundle without a bridge or significant glue code.
• The roadmap needs a provider-agnostic hosting abstraction, not an All-Inkl-specific bundle.
• The team requires vendor packages to maintain mutation testing or a broader quality gate than PHPStan + PHPUnit.
• There is no active need for All-Inkl integration; adopting the package would add dependency surface without product value.
• The team needs documented security guarantees, a published support policy, or a feature roadmap that this release does not demonstrate.

How to Pitch It (Stakeholders)

For executives: 1.8.0 is a maintenance release, not a product capability release. It modernizes the package’s development tooling and raises the PHP runtime floor by dropping PHP 8.2. There are no customer-facing features, so it should not change roadmap priority or external messaging. The business decision is whether the product needs All-Inkl integration and whether the team is ready to standardize on PHP 8.3+. If yes, this is a low-drama dependency to evaluate; if no, defer.

For engineering: Treat 1.8.0 as a dependency upgrade with a runtime constraint change. Verify PHP 8.3+ everywhere, check Composer resolution against PHPUnit 12 / PHPStan 2 / Symfony DI test 6, and run integration tests before merging. Expect no API changes from the release notes, but confirm the Symfony bundle fits the target application; do not assume Laravel-native support. Note that Infection and Psalm were removed from the package’s own pipeline—if your quality bar depends on mutation testing or Psalm, cover that at the application level or stay on the prior version until validated. Isolate the integration behind an internal adapter so the package remains replaceable.