Laravel Bigquery Laravel Package

Product Decisions This Supports

• Platform modernization sequencing. 1.7.0 drops PHP 7 and Laravel 8 and below. Any package that silently narrows its support matrix becomes a hard dependency gate on our Laravel 9+/PHP 8+ upgrade. This release is a scheduling input for that roadmap, not just a dependency bump: if we are still on Laravel ≤8, we are now pinned to the frozen 1.6.x line.
• Support-matrix ownership. The decision this release forces is "what is the oldest PHP/Laravel we commit to supporting, and for how long?" That should live as a written matrix (package version × PHP × Laravel) owned by product and enforced in composer.json and CI — otherwise this class of break gets discovered during an unrelated release.
• Build vs. buy. A single-maintainer package whose minor release (1.7.0) removes two major platform versions is worth re-scoring. If the integration surface is thin, inlining the behavior may cost less over a 12–18 month horizon than absorbing an unpredictable break cadence. This is a re-evaluate, not a replace — confirm the surface area first.
• Cache behavior risk (verify before shipping). The symfony/cache bump is the user-visible half of this release. Before upgrading, confirm whether cache key construction, TTL/expiry semantics, or serialization changed. If caching backs anything a user sees (feeds, pricing, permissions, session-adjacent data), a silent semantics change is a correctness incident, not a chore. This needs engineering verification — it is not answerable from the release notes alone.
• SemVer signal for the maintainer relationship. Dropping PHP 7 / Laravel ≤8 in a minor version bump is a compatibility break shipped under a non-breaking version number. PM-level read: treat every release from this package as potentially breaking, and pin exact versions with a tested-upgrade step.

When to Consider This Package

Adopt / stay on 1.7.0 when:

• You are already on PHP 8.0+ and Laravel 9+. The upgrade is then a routine symfony/cache bump plus a regression pass on cached paths.
• You want the maintained line. 1.7.0 is the version receiving fixes; staying on 1.6.x means no further patches, including security ones routed through symfony/cache.
• The caching behavior it wraps is non-critical or well-covered by tests you already have.

Look elsewhere, or freeze deliberately, when:

• You are on PHP 7.x or Laravel ≤8. You cannot take 1.7.0. Pin ^1.6 explicitly (an unpinned ^1.0 constraint will resolve to 1.7.0 and break your build), and record the freeze date and exit condition. This is a time-boxed decision, not a resting state.
• You need a predictable LTS window or a formal deprecation policy. This release provides neither — the support drop landed with no deprecation cycle visible in the notes.
• You cannot tolerate breaks in minor versions. If this package sits in a regulated, audited, or long-term-support product, the version-bump discipline is a mismatch.
• The transitive symfony/cache upgrade conflicts with a version pinned elsewhere in your tree. Resolve the tree-wide constraint before committing to 1.7.0 — this is the most likely place the upgrade actually fails.

How to Pitch It (Stakeholders)

For executives (3 sentences): A dependency we use has released version 1.7.0, which drops support for PHP 7 and Laravel 8 and below. If we are on those versions, we are now on an unsupported branch of this package and inherit its risk; the fix is a platform upgrade we likely already have on the roadmap. This costs us a scheduling decision and a testing pass, not new feature work.

For engineering leads: 1.7.0 removes PHP 7 and Laravel ≤8 support and updates symfony/cache. Three asks: (1) check whether any service or app is on the affected versions and, if so, pin ^1.6 today — an unpinned constraint will resolve forward and break the build; (2) audit the dependency tree for symfony/cache version conflicts across packages before merging the bump; (3) treat the cache upgrade as behavior-changing until proven otherwise — run the cache-dependent test paths and diff key/TTL/serialization behavior. Note that the platform drop shipped in a minor version, so we should pin and stage upgrades rather than float.

Framing for the "why now": the maintained line is the one that gets patches. Every sprint we stay on 1.6.x is a sprint without upstream fixes; every sprint we stay on Laravel 8 is an accumulating platform risk. The cheapest moment to absorb this is a planned upgrade, not an incident.