Laravel Vapor Response Compression Laravel Package

Product Decisions This Supports

• Framework upgrade planning. Release 3.3.0 adds Laravel 13 support and removes Laravel 11. This is the clearest signal in the release: the package tracks Laravel's support window rather than carrying legacy branches indefinitely. A PM can use that to sequence platform upgrades — if your Laravel 13 migration is on the roadmap, this package is not a blocker as of 3.3.0; if you are still on Laravel 11, this release is a hard stop and pins you to 3.2.x.
• Build vs. buy. A package that ships framework-version parity within the same release cycle as the framework itself, and that maintains PHPStan typing and a working test suite, is absorbing maintenance work your team would otherwise own. That lowers the effective cost of the "buy" option and weakens the case for an in-house implementation whose upgrade burden lands on your engineers every Laravel major.
• Dependency risk register. Dropping Laravel 11 is a deliberate support-policy decision, not an accident. It tells you the maintainer's cutoff is roughly "current and previous major." Put that in your dependency register so the next forced upgrade is a scheduled item, not a surprise.
• CI and quality gates. The PHPStan and test fixes indicate static analysis and an automated suite are part of the maintainer's release process. That is a meaningful input to whether you require a green analysis baseline before adopting a transitive dependency.
• Roadmap inputs. "Laravel 13 support" is a compatibility milestone, not a feature milestone. Do not book user-facing value against this release; book it as reduced upgrade risk.

When to Consider This Package

Adopt when:

• Your application is on Laravel 12 or 13. On 13, 3.3.0 is the first supported version.
• You want a dependency whose maintainer demonstrably follows framework support windows and ships compatibility promptly.
• Static-analysis cleanliness matters to your codebase — the PHPStan fixes suggest the package is meant to be consumed inside a type-checked project without suppressions.
• You can accept a rolling support policy of roughly two Laravel majors.

Look elsewhere, or stay pinned, when:

• You are on Laravel 11 or earlier. 3.3.0 removes it. Either stay on 3.2.x with a documented end-of-life date, or treat the framework upgrade as a prerequisite. Do not assume the 3.2 branch will receive security fixes — confirm that with the maintainer before relying on it.
• You need a vendor with a contractual long-term-support commitment. The rapid removal cadence is efficient but it is not LTS.
• Your upgrade cadence is slower than the framework's. You will be forced onto Laravel majors on the maintainer's schedule, not yours.
• The package's core domain functionality is unproven for your use case. This release says nothing about feature scope; it is a maintenance release. Evaluate capability separately before adopting.

Verification before commitment: confirm 3.2.x will still receive security patches, and confirm Laravel 13 support was tested rather than only declared — "some testing errors" fixed alongside a new framework major is worth a look at the CI matrix.

How to Pitch It (Stakeholders)

For executives: This is a routine maintenance release for a Laravel dependency, and the message is about upgrade risk, not new capability. The package now supports Laravel 13 and no longer supports Laravel 11. That means it will not hold back our framework upgrade, and it also means we cannot defer that upgrade indefinitely. There is no new spend and no new feature to sell — the value is a smaller, more predictable upgrade queue.

For engineering: Version 3.3.0 adds Laravel 13 support, drops Laravel 11, and cleans up PHPStan typing and test failures. Adopt on Laravel 12/13; anyone on 11 stays on 3.2.x with a dated exit plan. Before we commit, two checks: that 3.2.x still gets security fixes, and that the Laravel 13 CI job is real. Assume roughly a two-major support window going forward and plan our framework cadence against it rather than reacting to it.