Spreadsheetbundle Laravel Package

Product Decisions This Supports

• Platform upgrade planning (the main decision): v3.0.0 raises the floor to PHP >= 8.2 and pins Symfony ~7.1. In practice this means the package now only runs on modern Laravel stacks (Laravel 11+ on PHP 8.2/8.3), so adopting v3 is a platform decision, not just a dependency bump. Use this to decide whether the PHP 8.2 migration is pulled forward this quarter or the integration stays pinned to v2.x.
• Build vs. buy / pin vs. upgrade: if the product still runs PHP 8.1 (Laravel 9/10 era), the decision is "pin to v2.x and accept maintenance debt" versus "fund the runtime upgrade." v3 gives no middle option — worth stating explicitly in the roadmap.
• Roadmap sequencing: because v3 ships only platform constraints (no features, no deprecations listed), it clears the path for future feature work rather than delivering value now. It's a prerequisite ticket, not a value ticket — schedule it alongside the PHP upgrade, not standalone.
• Ecosystem lock-in assessment: the Symfony ~7.1 pin means the package's compatibility window is now coupled to Symfony's release cadence. That affects long-term support commitments (LTS choices, how often we'll be forced to upgrade).
• Use cases largely unchanged: the functional capability the package provides is the same as v2; adoption decisions should be driven by fit-to-problem, and v3 is evaluated on "can our runtime run it," not "does it do more."

When to Consider This Package

Adopt v3.0.0 when:

• The application is already on PHP 8.2+ and a Laravel version whose Symfony dependency resolution accepts ~7.1.
• You are planning a PHP/Laravel upgrade and want a dependency that is aligned with a forward-looking stack rather than one still supporting EOL runtimes.
• Long-lived product with a maintenance budget for periodic platform upgrades — v3 signals the maintainer intends to track current PHP/Symfony, which is a good sign for ongoing support.

Look elsewhere or stay on v2.x when:

• You are pinned to PHP 8.1 or below, or to a Laravel/Symfony combination that conflicts with Symfony 7.1. Upgrading this package becomes an application-wide platform migration.
• You need to support customers on older runtimes (multi-tenant, on-prem, or shared-hosting deployments where PHP version is outside your control).
• You require a documented migration path: the notes list only two constraint changes, with no upgrade guide, no changelog of code-level breaking changes, and no deprecation notice. Verify by diffing the tags before committing; if the internals changed, ask the maintainer to publish a migration guide.
• You need LTS-style stability and the Symfony 7.1 minor pin implies frequent coordinated bumps.

How to Pitch It (Stakeholders)

For executives (one line): A dependency we use has released a new major version whose only change is requiring a newer PHP runtime (8.2+) — it delivers no new features, so the cost is purely the platform upgrade it forces, and staying on the previous major remains a supported option short term.

For engineering leads: Treat v3.0.0 as a breaking release by constraint, not by API. Two things to verify before merging:

1. Confirm the project's PHP version and Composer-resolved Symfony constraint accept ~7.1; otherwise expect a resolution conflict requiring --with-all-dependencies or a broader framework upgrade.
2. Diff v2.x against v3.0.0 to catch undocumented code-level changes — the release notes don't mention any, which isn't the same as there being none.

Recommended position: Do not upgrade opportunistically. Bundle v3 adoption into the planned PHP 8.2/Laravel upgrade as a single tracked workstream; until then, pin to v2.x and record the debt. Ask the maintainer to publish a migration note and to confirm whether v2.x will continue receiving security fixes — that answer determines whether pinning is a safe holding pattern or a deadline.