Resource Bundle Laravel Package

Product Decisions This Supports

• Dependency and EOL planning. v3.0.0 is a compatibility release: it moves the package onto the Symfony 4 baseline. Symfony 4 is the component baseline for Laravel 5.6+ (PHP 7.1.3+), so this release is about staying on a supported framework generation — it is not a feature investment.
• Roadmap sequencing. A semver-major bump means scheduled engineering work, not an opportunistic composer update: pin the current 2.x line, plan a regression window, then move. Budget for a test pass, not for new capability.
• Build vs. buy. The relevant question isn't "is Symfony 4 support good?" (it is table stakes) but "is this dependency's upgrade cadence cheaper than owning the behavior ourselves?" A major version whose only change is a dependency bump implies maintenance-mode stewardship; factor that into any replace-vs-keep analysis.
• Release cadence as a health signal. Track whether 3.x picks up features and fixes after this bump. A major version with a one-line changelog and no migration guide is a data point about maintainer responsiveness, and should temper any roadmap dependency on this package.
• Version selection by product surface. Anything still on Laravel ≤5.5 / Symfony 3 must remain on 2.x; anything on a current Laravel should start at 3.x. That split is a customer-segmentation and support-policy decision, not just an engineering one.

When to Consider This Package

Adopt when:

• Your Laravel baseline already ships Symfony 4 components (Laravel 5.6+, PHP 7.1.3+), so the package's constraints resolve without forcing a framework upgrade.
• The functionality is adjacent to your core product and you'd rather buy than build.
• You can absorb a semver-major upgrade every year or two and have test coverage to make it uneventful.

Look elsewhere, or stay pinned to 2.x, when:

• You are on Laravel ≤5.5 or PHP below 7.1.3 — 3.0.0 will not resolve, and there is no indicated backport path.
• You need an LTS-style guarantee. A dependency-only major bump is not a support commitment, and the release note offers no deprecation policy or roadmap.
• You require documented upgrade risk. The 3.0.0 note is a single line with no migration guide, no "what broke" list, and no linked changelog; treat the blast radius as unknown until you read the diff and composer.json constraints yourself.
• You are already carrying Symfony-4-era dependencies elsewhere and this package's version churn is the only thing moving — in that case the migration cost is real and the benefit is marginal.

How to Pitch It (Stakeholders)

For executives: v3.0.0 is a maintenance release that keeps a third-party dependency on a supported Symfony baseline. The cost is one upgrade cycle plus regression testing; the benefit is retiring EOL exposure and staying aligned with our framework version. Low strategic risk, low strategic upside — approve it as housekeeping, not as a capability bet.

For engineering: it's a semver-major, so treat it as breaking by default. The release note reads only "Bump support for Symfony 4," which almost certainly means Symfony 3 support was dropped and possibly older PHP/Laravel constraints with it. Pin 2.x, read the diff and the new composer.json constraints, and run a full regression pass before bumping. If the maintainer hasn't published a migration note, request one or produce an internal one — do not merge blind on a one-line changelog.

For product: no user-facing change is documented here, so this should not consume roadmap capacity beyond the upgrade ticket. Revisit the dependency's strategic weight only if 3.x fails to accumulate features and fixes over the next few releases; that pattern would argue for evaluating alternatives at the next planning cycle.