Picasso Laravel Package

Product Decisions This Supports

• Build vs. buy / adopt: The 0.8.0 changes are maintenance-oriented, not feature-oriented. They are a signal about the maintainer's engineering standards rather than new capability. Treat this release as evidence of project health (typed, modern, statically-analyzable code) rather than as a reason to adopt on functionality grounds.
• Upgrade/downgrade timing on the roadmap: Because this touches the public API surface (parameter names) and minimum tooling expectations (native type declarations imply a modern PHP floor), it belongs in a scheduled dependency-bump slot, not a hotfix slot. Budget a ticket for consumer-side call-site review if your code invokes the package with positional arguments.
• Technical-debt reduction: Native types replacing docblocks raises the ceiling for static analysis (PHPStan/Psalm levels), improves IDE autocomplete and refactor safety, and reduces the class of bugs that only surface at runtime. If a "raise static analysis strictness" or "reduce runtime type errors" epic exists, this release is a supporting input.
• Onboarding and bus-factor planning: Typed signatures are self-documenting. For teams inheriting a codebase or rotating engineers through it, this lowers ramp-up cost on every integration point with the package.
• API stability policy: Named parameters make parameter names part of the public contract. Any future rename of a parameter becomes a breaking change even if types and order are unchanged. This should be captured in your dependency policy — see the version-pinning note below.
• Use-case fit is unchanged: 0.8.0 does not expand or narrow what the package can do. Do not use this release to justify a new use case; use it only to reassess risk, maintenance cost, and upgrade effort.

When to Consider This Package

Consider adoption when:

• Your codebase targets a PHP version that supports the syntax the package now requires. Native type declarations and named-argument call sites both imply a modern PHP floor — confirm the package's composer.json constraint before committing.
• Your team already runs static analysis (PHPStan, Psalm, Larastan). Typed signatures are where this package now pays off; without a static analyzer in CI you capture only a fraction of the benefit.
• You are willing to pin the dependency. At 0.8.0 the package is pre-1.0, where semantic versioning explicitly permits breaking changes in minor releases. Pin to a minor range and review each bump, or expect surprise breaks.
• You are calling the package directly rather than only through a framework integration layer — direct callers are the ones exposed to parameter-name changes.
• The package is a candidate for a long-lived part of your stack. The docblock-to-types and positional-to-named migration pattern is what a maintainer does when preparing for a stable 1.0, which is a reasonable proxy for intended longevity.

Look elsewhere when:

• You need API stability guarantees today. Pre-1.0 means the surface can still move; if you cannot absorb a breaking change on a minor bump, wait for 1.0 or choose an alternative with a stable major line.
• You are locked to an older PHP runtime that cannot satisfy the new type syntax.
• Your team uses named arguments heavily and would be directly exposed to parameter renames — factor the churn cost in explicitly.
• The package is peripheral and trivially replaceable. The upgrade effort is small but non-zero; for a leaf dependency, swapping may cost less than tracking the release cadence.
• You require a published deprecation/support policy. The notes describe an internal cleanup, not a migration guide — if there is no upgrade documentation, treat that as a maturity signal.

Due diligence note: no external data (downloads, issue activity, maintainer count, security advisories, downstream breakage reports) was supplied with this release. The above is derived from the release contents alone; validate against the package's actual adoption and maintenance metrics before making a commitment decision.

How to Pitch It (Stakeholders)

To executives: This is a routine quality release for a pre-1.0 dependency — no new features and no capability change, so there is no direct product impact. It matters only as a small, positive signal about the health of a component we depend on: the maintainer is modernizing the codebase, which tends to correlate with fewer defects and easier long-term maintenance. The cost is a scheduled dependency bump; the risk is low but not zero because the project is still pre-1.0 and this release can break call sites. Recommendation: approve the bump as planned maintenance, keep the version pinned, and do not treat it as a reason to expand usage.

To engineering: Two changes, both API-visible. (1) Docblocks are replaced with native type declarations — you gain IDE inference and static-analysis coverage, but the package now requires a PHP version that supports those types; check the constraint before upgrading. (2) Positional parameters are replaced with named parameters — call sites that pass arguments positionally may need updating, and going forward parameter names are public API, so any upstream rename is a breaking change for us. Action items: bump in a dedicated PR, run the full test suite plus static analysis, audit direct call sites for positional usage, and pin to the current minor range until the package reaches 1.0. Do not fold this into an unrelated feature branch.