Linen Laravel Package

Product Decisions This Supports

• Build vs. buy (or borrow): Adopting this package delegates a capability to a maintained dependency instead of custom in-house code. The 0.1.0 release is primarily a maintenance signal — Laravel 13 support means the dependency is unlikely to become a blocker on your next major framework upgrade.
• Roadmap sequencing / platform upgrade planning: If Laravel 13 is on the roadmap, this release is the gate that lets the package stay in the stack through that upgrade. If you're on Laravel 11/12, treat 0.1.0 as "not yet applicable" until you confirm the supported version matrix.
• Upgrade cadence and technical-debt budgeting: Because the package is pre-1.0, semver gives weaker guarantees — a 0.x minor bump (0.0.4 → 0.1.0) may include breaking changes. This informs whether you pin exact versions, adopt a scheduled upgrade slot, or absorb changes ad hoc.
• Vendor/dependency risk and exit planning: Single-package, early-stage, short release history. Decide how much surface area to depend on and whether to wrap it behind an internal interface so a future swap is a contained change rather than a refactor.
• Scope decisions: If the capability it provides is small relative to the overhead of tracking its version constraints, that's a legitimate argument for in-house implementation instead.

When to Consider This Package

Consider it when:

• You are on — or actively planning — Laravel 13 and need the behavior it provides; 0.1.0 is the release that claims that support.
• You want a dependency whose release cadence visibly tracks Laravel majors, so framework upgrades don't strand you.
• The functionality is non-trivial enough that maintaining it yourself would cost more than tracking an upstream package.
• You can tolerate pre-1.0 versioning by pinning versions and testing upgrades on a branch.

Look elsewhere, or proceed with explicit caveats, when:

• You're on Laravel 10–12 and have not verified whether 0.1.0 dropped support for your version. The release notes say only "Adds Laravel 13 support" — they do not state that older versions were retained or removed. Check composer.json and the CI matrix before upgrading.
• You require a 1.0+ stability guarantee, a published support/LTS window, or a deprecation policy.
• Your procurement rules require multi-maintainer projects or commercial support options.
• The feature set is thin enough that in-house code is cheaper than the ongoing version-tracking and upgrade-testing overhead.
• You cannot accept breaking changes arriving in a minor version bump; without a wrapper layer, that risk lands directly on your application code.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-commitment dependency that keeps pace with the framework. The 0.1.0 release adds Laravel 13 support, which removes a future upgrade blocker and reduces the chance we're forced into an unplanned rewrite or vendor swap during our next platform upgrade. The main risk is concentration: it's an early-stage (pre-1.0) package, so its API may shift. We mitigate that cheaply by pinning versions and, if it becomes load-bearing, wrapping it behind an internal interface so replacing it stays a contained change. Recommendation: keep it, upgrade deliberately rather than automatically, and revisit if it stops shipping alongside Laravel releases.

For engineering:

• 0.1.0 adds Laravel 13 support. No breaking changes are announced, but this is a 0.x minor bump — treat it as potentially breaking and read the diff, not just the notes.
• Verify the constraint matrix first: confirm in composer.json which Laravel and PHP versions 0.1.0 actually allows, and whether older Laravel support was dropped. The notes are silent on this, and it's the single highest-value thing to check.
• Run the upgrade on a branch with the full test suite; pin the exact version in composer.json rather than floating on ^0.1.
• If we depend on it in more than one or two places, introduce a thin internal adapter so future major/breaking releases are a one-file change.
• Track its release cadence going forward. The package's value proposition here is largely "keeps up with Laravel" — if that stops being true, that's our trigger to re-evaluate.