Laravel Bento Laravel Package

Product Decisions This Supports

• Platform baseline / upgrade sequencing. v2.9.0 drops Laravel 11 and moves the PHP floor to 8.4. This is a forcing function: the package is now only usable on a Laravel 12+ / PHP 8.4+ stack, so any roadmap item that depends on it inherits that upgrade prerequisite.
• Build vs. buy vs. fork. A dependency that narrows its supported platform window on a minor release raises the cost of staying current. This is a prompt to decide whether to (a) ride the upstream release train, (b) pin to 2.8.x and absorb maintenance ourselves, or (c) fork/vendor the package if the feature surface we rely on is small.
• Support matrix commitment. If we ship this package as part of a product offering, its supported PHP/Laravel versions become our supported versions. That is a customer-facing commitment, not just an internal engineering detail.
• Release-risk review. The change is labelled feat: but is functionally breaking (removes framework support). It shipped as a minor bump (2.8.0 → 2.9.0), which means caret constraints such as ^2.8 will float onto it. Confirm Composer's platform constraints are what is actually protecting our Laravel 11 apps, rather than assuming semver will.
• Deprecation communication. Anyone on Laravel 11 or PHP 8.2/8.3 needs a dated "do not upgrade past 2.8.x" note in internal docs and onboarding material.

When to Consider This Package

Consider it when:

• Your application estate is already on Laravel 12+ and PHP 8.4+, or will be within the current planning horizon.
• You want a maintained, actively released dependency and are comfortable tracking a fast-moving upstream (two minor releases in the recent window).
• The capability it provides is genuinely non-differentiating for you — i.e. you would otherwise build and maintain it yourself.

Look elsewhere / defer when:

• You run Laravel 11, or PHP 8.2 or 8.3, anywhere in the estate. Pin 2.8.* explicitly; do not rely on ^2.8.
• You need a dependency with an explicit LTS or multi-version support policy. This release signals the maintainer is willing to drop framework majors on minor versions, which is a poor fit for long-support product lines.
• You are mid-migration and cannot afford a hard coupling between a feature delivery and a platform upgrade.
• The package's surface area you use is small enough that an in-house implementation is cheaper than the upgrade coupling.

Immediate action regardless: add an explicit constraint ("exolnet/laravel-bento": "2.8.*") to any Laravel 11 project, rather than a caret range, and verify the lockfile has not already floated.

How to Pitch It (Stakeholders)

For executives: A dependency we use released an update that drops support for our current Laravel and PHP versions. Nothing breaks today — our lockfiles hold — but the package is now only compatible with a stack we have not finished migrating to. The decision this forces is timing, not functionality: either we bring forward the Laravel 12 / PHP 8.4 upgrade, or we freeze this dependency at its current version and carry a small ongoing maintenance cost. I recommend freezing now and folding the upgrade into the already-planned platform work rather than treating it as a separate initiative.

For engineering: v2.9.0 removes Laravel 11 support and sets the PHP requirement to 8.4. It is a breaking change published as a minor version, so ^2.8 constraints are not a safety net — Composer's platform requirements are the only thing preventing an incompatible install. Pin to 2.8.* on Laravel 11 branches, add PHP 8.4 to the CI matrix before any upgrade attempt, and treat the bump as a scheduled change rather than an incidental composer update. Confirm whether the feat: prefix in the changelog reflects intent or a labelling slip, and raise it upstream — if the maintainer intends to keep dropping framework majors on minors, we need an explicit stance on tracking this package at all.