Laravel Brickables Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing. 3.2.0 confirms Laravel 10 support and drops Laravel 8. This is the signal a PM needs to decide whether the Laravel 10 migration is "this quarter" (package is ready) or "blocked on a dependency" (it is not). Treat the package's supported-version matrix as a gating item in the platform-upgrade plan, not an afterthought.
• Build vs. buy. A compatibility release shipped for a new Laravel major is evidence of active maintenance. That is the strongest argument for adopting/keeping the package over an in-house reimplementation: you would otherwise own this migration work yourself every 12–18 months.
• Support-matrix fork on the roadmap. Dropping Laravel 8 splits the fleet: Laravel 9/10 services move to the 3.2.x line, Laravel 8 services must pin to the prior minor (3.1.x). That is a planning item — it sets a deadline for finishing the Laravel 8 exit, and it means two supported dependency versions to track in the interim.
• Runtime/platform decisions. The PHP 8.1/8.2 lock makes PHP version a first-class constraint on the infrastructure roadmap. Any plan to standardise on PHP 8.3 is now coupled to a future release of this package.
• Use cases unlocked. Any Laravel 9 or 10 application on PHP 8.1/8.2 can adopt without caveats. Laravel 8 applications can adopt only by pinning to the previous line, which freezes them out of future fixes.

When to Consider This Package

Adopt when:

• The application is on Laravel 10, or Laravel 10 migration is planned within the next one to two quarters.
• Runtimes are standardised (or standardisable) on PHP 8.1 or 8.2.
• You want a dependency with a demonstrated record of following Laravel majors rather than lagging them.
• You are willing to accept the maintainer's compatibility cadence as your own.

Look elsewhere or defer when:

• You are still on Laravel 8. This release is a hard incompatibility, not a deprecation warning. You can stay on 3.1.x, but you are now on an unmaintained branch and should timebox that state.
• Your platform is on, or committed to, PHP 8.3+. The lock to 8.1 and 8.2 means the package will not install there. Confirm the maintainer's intent to widen this before it becomes your blocker.
• You need longer support windows than the maintainer publishes. A version policy that drops a Laravel major this quickly is fine for fast-moving product teams and wrong for long-lived, slow-release enterprise deployments.
• Your compliance posture requires a documented support policy. There isn't one in the release notes; ask for it.

Caveat on scope. The 3.2.0 notes describe compatibility changes only — no new functionality and no deprecations are listed. Functional due diligence (what the package actually does and whether it fits the use case) is unchanged by this release and should not be inferred from it.

How to Pitch It (Stakeholders)

For executives. This is a maintenance release with no new features and no user-visible change. It is still decision-relevant for one reason: it tells us the package is keeping pace with Laravel 10, so it will not hold up our framework modernisation. The cost of action is a version bump; the cost of inaction is being stranded on an unsupported branch when we finish the Laravel 8 exit.

For engineering. Three things to act on:

1. Upgrade path is a version bump for services already on Laravel 9/10 and PHP 8.1/8.2 — no code changes are indicated by these notes.
2. CI matrix needs updating. Add Laravel 10, remove Laravel 8, and pin the PHP versions to 8.1 and 8.2. Services still on Laravel 8 must pin the dependency to 3.1.x and get a dated ticket to migrate off it.
3. PHP 8.3 is a known future blocker. The version lock is explicit, so any 8.3 upgrade plan must include verifying a later release of this package. Flag it now rather than discovering it during an infrastructure change.

What I'd ask the maintainer: the intended support window for 3.1.x, and whether the PHP 8.1/8.2 lock is temporary or a policy. Those two answers decide how much urgency the Laravel 8 exit and the PHP 8.3 plan actually carry.