Apposite Laravel Package

Product Decisions This Supports

• Laravel upgrade timing (the primary signal here). v5.0.0 requires PHP 8.3 and Laravel 13, and the maintainers have declared that only the latest Laravel major is supported going forward. This package's version number is now effectively a proxy for your platform version — adopting v5 forces a decision about when your application moves to PHP 8.3 / Laravel 13, and that decision should be made on your own roadmap, not by the package.
• Support-lifecycle policy (a decision you now have to make explicitly). "Latest major only, older versions no longer maintained" is a deliberate maintenance-posture choice, not a bug. It means you inherit responsibility for security patching on any older-major deployment. That is a policy decision for the PM/eng lead: either commit to tracking upstream within one major, or pin a tagged release and accept that you own the patches.
• Build vs. buy. The release is dominated by hygiene work — Laravel Pint, PHPUnit 12, removed Node tooling, removed Scrutinizer, Podman-based dev. That is a maintainer choosing to shrink their own surface area. For a build-vs-buy call, this reads as a small, lean, opinionated project rather than a heavily-resourced one: cheap to adopt, but don't expect long-tail support.
• Developer-environment standardization. The ./dev Podman workflow removes the host PHP/Composer requirement. This is a concrete onboarding and CI-parity decision: it lowers setup friction for new contributors and makes "works on my machine" less likely, but it introduces a Podman dependency into your onboarding docs.
• CI/tooling consolidation. Dropping Node tooling and Scrutinizer simplifies your pipeline if you mirror the package's choices, and removes two moving parts from any fork or contribution workflow.
• Use cases. Best suited to internal tooling, admin/back-office surfaces, and greenfield Laravel 13 services where being on the current major is already the default. Poor fit for long-lived products on a slow, vendor-certified upgrade cadence.

When to Consider This Package

Adopt when:

• You are on, or are willing to move to, Laravel 13 and PHP 8.3 within this package's support window.
• Your team is small and benefits from the maintainer's leaner toolchain (Pint, PHPUnit 12, containerized dev) rather than fighting it.
• You can accept "latest major only" and have a credible plan for either staying current or pinning and self-patching.
• Your developers can run Podman (or you're willing to maintain a parallel non-Podman dev path).

Look elsewhere when:

• You are pinned to Laravel 11 or 12 for contractual, compliance, or migration-cost reasons. v5.0.0 offers you nothing, and the previous line is explicitly unmaintained — pin a tagged release and treat it as frozen, or pick an alternative with an LTS/backport policy.
• You require vendor-provided security backports on older majors. This project has stated it will not do that.
• You are on Windows or a non-Podman environment and don't want to own a second dev setup.
• Your CI still depends on Scrutinizer or Node-based asset/lint steps that this project has now removed from its own workflow.
• Caveat worth flagging to stakeholders: these release notes describe maintenance and tooling changes only. They contain no functional information about what the package does, so feature fit must be assessed separately — this release alone is not evidence of capability, only of maintenance posture.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small Laravel/PHP package that has just cut a major version to stay aligned with the current Laravel and PHP releases. The practical consequence is that adopting it commits us to the current platform generation (PHP 8.3 / Laravel 13) — which is where we're headed anyway, but it means the package can no longer be used as a reason to defer that upgrade. The maintainer has also been explicit that only the newest Laravel major will be supported from now on, so this is a "stay current or own the maintenance yourself" relationship rather than a long-term-support one. Low adoption risk, low switching cost, and no functional changes in this release; the real decision it forces is about our own upgrade cadence.

For engineering (bullet summary):

• v5.0.0 is breaking: PHP 8.3 + Laravel 13 required. Budget the upgrade as a platform migration, not a dependency bump.
• Support model is "latest Laravel major only." Old majors are unmaintained — pin a tag if we must stay on one, and log that we now own security patching for it.
• Toolchain aligned to Laravel defaults: Pint for linting, PHPUnit 12 for tests. Expect noise in our linters and test config if we contribute or fork.
• Dev environment moves to Podman via ./dev, with no host PHP or Composer needed. Update onboarding docs; confirm Podman is acceptable on our standard dev images before we mandate it.
• Node tooling and Scrutinizer CI support are gone — audit any pipeline steps that assumed them.
• Recommendation: adopt if we're tracking Laravel 13; otherwise pin the last compatible tag, record it as a known-frozen dependency, and schedule the upgrade against our own roadmap rather than reacting to this release.