Request Token Bundle Laravel Package

Product Decisions This Supports

This release is a platform-baseline change, not a feature change — frame your decisions accordingly.

• Runtime roadmap commitment: v1.2.0 raises the floor to PHP 8.2 and Symfony 7.4. Adopting this version is functionally a decision to commit to that platform baseline, not merely a library upgrade. If your fleet, CI images, and deploy targets are not already there, this release converts a dependency bump into an infrastructure project.
• Upgrade sequencing: Because a minor version carries a hard minimum bump, treat this project's releases as semver-adjacent rather than safely patch-level. Budget for coordination between the package upgrade and your PHP/Symfony upgrade, not just a composer update.
• Build vs. buy: A maintainer actively tracking current PHP and Symfony lines — rather than pinning to EOL runtimes — is a positive maintenance signal. That lowers the long-term total cost of ownership relative to forking or vendoring, and it reduces the odds of being stranded on an unsupported branch later.
• Standardization leverage: If the org is already standardizing on PHP 8.2+, this release aligns with that direction and can be used as a supporting argument. If the org is not, this is a concrete blocker that should be sized and scheduled.
• Evidence limit: The release note describes the platform floor only. It does not tell us what the package does, so feature-level decisions (user-facing capability, use-case fit, competitive differentiation) cannot be made from this input alone. Pull the package README/API surface before committing to a use case.

When to Consider This Package

Adopt when:

• Your application, CI pipeline, local dev containers, and production images are all on PHP 8.2 or higher.
• Your host application is on, or is scheduled onto, Symfony 7.4.
• You can absorb a runtime-floor change within a normal release cycle rather than a quarterly planning cycle.
• You value an actively maintained upstream over a floor-stable dependency.

Look elsewhere when:

• You are pinned to PHP 8.0/8.1 or Symfony 6.x with no funded upgrade path. This version is simply not installable for you, and you would be adopting a fork or an older branch — both are maintenance liabilities.
• Your platform policy requires dependencies whose minor versions never raise the runtime floor (LTS-aligned or floor-stable libraries).
• The package sits on a critical path where an unexpected minimum-version bump would block a hotfix release.
• The package's actual functionality has not yet been evaluated against your use case — do not adopt on maintenance signals alone.

How to Pitch It (Stakeholders)

For executives (one paragraph): Version 1.2.0 of this package raises its minimum supported platform to PHP 8.2 and Symfony 7.4. This is a maintenance-health release, not a feature release — it tells us the maintainer is keeping pace with the current ecosystem rather than drifting toward end-of-life. The strategic upside is reduced long-term maintenance risk and a lower chance of a forced migration later. The cost is sequencing: teams still on PHP 8.1 or Symfony 6.x cannot take this version until their runtime upgrade lands. Recommendation: do not auto-upgrade. Adopt it as part of the existing PHP 8.2+ migration rather than ahead of it, and treat the runtime upgrade as the gating milestone.

For engineering (summary): Floor bump to PHP 8.2 / Symfony 7.4 in a minor version. Verify CI matrix, Docker base images, and any shared libraries still targeting 8.1. Run the full suite against 8.2 before merging, and pin explicitly if you need to stay on the prior branch. Confirm no transitive dependency conflicts with your Symfony 7.4 constraint before scheduling the bump.