Rest Bundle Laravel Package

Product Decisions This Supports

• Logging/observability integration choices: v0.8.1 widens the psr/log constraint to ^2 and ^3, which means the package now drops into applications and libraries built against modern PSR-3 versions without dependency-conflict surgery. That directly de-risks any roadmap item that touches structured logging, error reporting, or audit trails.
• Framework-version upgrade planning: Laravel 10/11 stacks increasingly ship with psr/log v3. A package pinned to older constraints becomes a blocker in monorepo-wide upgrades. This release removes that blocker, so it can be scheduled alongside (rather than ahead of) framework modernization work.
• Build vs. buy: If the alternative is hand-rolling logging glue inside each service, the widened compatibility lowers the "buy/integrate" cost to near zero. The remaining evaluation is functional fit, not installation friction.
• Ecosystem/interoperability positioning: PSR-3 support matters if we need the same logging backend shared across Laravel services, Symfony components, and non-Laravel PHP workers. It signals the maintainer intends to stay standards-compliant rather than vendor-locked.
• Maintenance signal for the vendor scorecard: A patch-level dependency unlock on a pre-1.0 package is a small but positive reliability indicator — the maintainer is tracking upstream releases rather than letting constraints rot.

When to Consider This Package

Consider it when:

• Our dependency tree already resolves psr/log v2 or v3 (typical on current Laravel and Symfony releases) and we need a package that won't force a downgrade or a Composer --with-all-dependencies fight.
• The product needs logging that crosses framework boundaries — Laravel app plus queue workers, CLI tooling, or shared libraries.
• We want a small, composable dependency rather than a full observability platform, at least for the first iteration.
• We are consolidating logging conventions across multiple services and want a standards-based contract (PSR-3) rather than a bespoke interface.

Look elsewhere when:

• The requirement is turnkey log aggregation, retention, alerting, or dashboards — this is a plumbing-level dependency, not an observability product.
• We need vendor-slotted handlers, sampling, or redaction guarantees that would have to be custom-built on top.
• The package's API surface is still pre-1.0: version 0.8.x means minor releases may carry breaking changes, so anything on the critical path needs a pinned version and a wrapper layer we control.
• Our platform is locked to psr/log v1 and cannot move — no benefit accrues, and the broader constraint set adds no value.

Adoption criteria: pin the exact version, add a thin internal adapter so a future break is a one-file change, and confirm the functional scope actually covers our handler/formatter needs before investing integration time.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, standards-aligned logging dependency, not a platform commitment. The newest release simply lifts a version ceiling so it installs cleanly on our current stack — it removes a roadblock rather than adding a feature. Risk is contained: it's pre-1.0, so we pin the version and wrap it, keeping exit cost to days, not quarters. Recommend approving a time-boxed pilot on a non-critical service.

For engineering: v0.8.1 relaxes psr/log to ^2 || ^3, so no more constraint conflicts with modern Laravel/Symfony trees. Caveats: the package is at 0.8.x, so treat minor bumps as potentially breaking — pin it and isolate behind our own logging interface. Validate handler and formatter coverage against our requirements before committing; the release note tells us about compatibility, not capability. Worth a spike this sprint given the low integration cost.