Stacked Dumper Laravel Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing. The release adds Laravel 13.x support while raising the floor to ^11.0. That makes it a direct input to your Laravel upgrade roadmap: if the product depends on this package, Laravel 11 is now the earliest viable target, and 13.x is unblocked. If you are still on Laravel 10, this version is not adoptable — that is a scheduling constraint, not a preference.
• Build vs. buy / maintain vs. fork. Dropping Laravel 10 and adding Laravel 13 in the same release is a positive maintenance signal: the maintainers are tracking upstream framework cadence rather than accumulating compatibility debt. For a buy/keep decision, this is evidence the package will not become the long pole in your next framework upgrade.
• Dependency and CI posture. The Docker image bumps (Composer 2.10.0, PHP 8.5) indicate active refresh of the development/CI toolchain. Relevant to supply-chain review and to whether your own CI can run the package's test suite on modern runners.
• Release scoping. All changes are compatibility and tooling; there are no new user-facing features and no deprecations called out. Treat v1.10.0 as a maintenance/upgrade-enablement release — it should not drive feature roadmap prioritisation, only platform decisions.
• Use-case fit is not evidenced here. This changelog says nothing about domain capability, so any build-vs-buy conclusion on functionality must come from a separate functional review; what this release validates is the durability half of that decision.

When to Consider This Package

Adopt or upgrade when:

• Your application is on Laravel 11, 12, or 13, or you are planning to move there within the current planning horizon.
• You need a dependency that stays current with Laravel major releases without you patching or forking it.
• Your CI/CD expects modern tooling (Composer 2.10-era, PHP 8.5-capable images) and you want the package's own pipeline to mirror that.
• You are doing a vendor-risk review and want a datapoint that the maintainers respond to upstream framework releases rather than lagging quarters behind.

Look elsewhere or defer when:

• You are pinned to Laravel 10 or earlier. The ^11.0 floor makes this release a hard break for you; either stay on an older package line or budget the framework upgrade first.
• You require a formal LTS guarantee or a long-term frozen dependency — the "minimal version moves with upstream" pattern here means periodic forced upgrades.
• You need a package that is conservative about minimum-version bumps (e.g. a large monolith that upgrades Laravel once every 18–24 months); the version floor will bite you between upgrades.
• Your functional requirements are unproven for this package. Nothing in this release describes domain features, so if you have not yet validated capability fit, do that before citing this release as a reason to adopt.
• You run older PHP runtimes in a constrained environment — verify the package's own PHP floor against your platform, since the changelog only names the Docker image's PHP version, not the library's require constraint.

How to Pitch It (Stakeholders)

For executives (one paragraph): v1.10.0 is a routine maintenance release that keeps this dependency aligned with current Laravel versions — it adds Laravel 13 support and drops Laravel 10, with no new features and no deprecations. The practical takeaway is risk reduction: the package will not block our next Laravel upgrade, and the maintainers are actively tracking upstream. The one decision it forces is that our own Laravel 11+ timeline becomes a prerequisite for taking this version; if we are still on Laravel 10, we schedule the framework upgrade before the package upgrade, not after.

For engineering (talking points): Low functional risk, non-trivial version risk. Changes are: Laravel 13.x added, minimum Laravel raised to ^11.0, Docker dev image moved to Composer 2.10.0 and PHP 8.5, dev dependencies refreshed. Because the minimum framework version moved, treat this as a minor-version-with-migration-cost rather than a drop-in patch — pin it deliberately, run the full suite and any Laravel-version-sensitive integration tests, and confirm your CI matrix covers the Laravel version you actually deploy. Verify the package's declared PHP require constraint independently of the Docker image's PHP 8.5, since the two are not the same signal. No new APIs to learn, no deprecation cleanup required.

Ask: confirm target Laravel version, confirm PHP runtime floor, then schedule the bump in a normal maintenance window.