Saferpay Bundle Laravel Package

Product Decisions This Supports

• Platform upgrade roadmap. v2.0.0 is framed entirely as Symfony 5.4 compatibility. That makes this release a dependency-modernization event, not a feature event — it belongs on the platform/infra roadmap, not the product feature roadmap.
• Build vs. buy (and buy vs. fork). A package still actively tracking upstream framework LTS lines is a "buy/keep" signal. If your org has forked or vendored this package, v2.0.0 is the trigger to evaluate whether to re-base on upstream or continue maintaining the fork — forking now costs you every future Symfony bump.
• Framework upgrade sequencing. If you are planning a Laravel/Symfony major upgrade, this package's 2.x line becomes a hard prerequisite in your dependency graph. That sequencing decision (upgrade the package first, or the framework first) is a PM-level scheduling call because it determines whether other work can merge.
• Maintenance budget allocation. Semver-major releases require an audit + regression cycle. That is engineer-days you should reserve explicitly rather than absorb into "overflow." A PM who doesn't allocate this gets a surprise slip in the next sprint.
• EOL / risk posture. Symfony 5.4 is an LTS line with a finite security window. A package aligned to 5.4 buys you time but signals that a further bump will be needed later — factor a second upgrade cycle into annual planning rather than treating this as a one-off.
• Procurement / vendor-health scoring. Release cadence and upstream-tracking behavior are quantitative inputs if this package is part of a due-diligence or dependency-approval review.

When to Consider This Package

Consider adopting or staying on it when:

• You are on Symfony 5.4 components (directly or via Laravel) and need a maintained, compatible integration rather than pinning a stale version.
• You want upstream-tracking behavior — a maintainer who ships a compatibility release promptly is more valuable than one with a richer feature list and a six-month lag.
• The package is a non-differentiating bridge/adapter in your stack. This is exactly the kind of thing to buy rather than build; you get the maintenance burden transferred.
• You have test coverage sufficient to validate a major-version bump cheaply. A 2.0.0 compatibility release is a low-cost upgrade if your suite is trustworthy and a high-cost one if it isn't.

Look elsewhere (or build in-house) when:

• You need Symfony 6.x/7.x support today. A 5.4-targeted release means the 6.x line is either not yet available or a separate future major — check the maintainer's stated trajectory before committing.
• The package is a thin wrapper over a few framework calls. If the integration surface is small, owning ~200 lines removes a recurring upgrade tax entirely.
• The major version is a breaking change with no migration guide. "Compatibility release" describes intent, not impact. If v2.0.0 drops support for older Symfony versions or changes public API, that is a real migration. No changelog or upgrade notes = adoption risk, regardless of how routine the release sounds.
• Release cadence is irregular or single-maintainer without a succession plan — a major bump is a reasonable moment to stress-test that dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a housekeeping release, not a capability release. The package has been updated to stay compatible with the underlying Symfony framework, which is the maintenance signal we want from a dependency — someone is watching upstream so we don't have to. There is no new functionality and no direct user-facing impact. The only decision it forces is a small, schedulable engineering task: a semver-major bump means we should verify nothing in our integration breaks before we adopt it. Cost is low and bounded; the value is continued supportability and avoiding a more expensive forced upgrade later.

For engineering:

• This is a major version bump (1.x → 2.0.0). Treat it as potentially breaking until proven otherwise — read the changelog and diff public API, dropped framework version support, and config/contract changes before merging.
• Scope the upgrade as a dependency audit + regression run, not a feature ticket. Estimate against your test suite's real coverage, not its nominal coverage.
• Confirm the supported version matrix post-upgrade. If 2.0.0 requires Symfony 5.4, verify nothing else in our graph is still pinned below it.
• Identify whether we are on a fork or a version constraint that will silently block the upgrade; resolve that before the sprint starts.
• Expect a follow-on bump when the maintainer targets Symfony 6.x. Note it in the dependency register now so it doesn't arrive as a surprise.

Framing to avoid: don't sell this internally as a "new version with improvements" — it has no features. Sell it as risk reduction and dependency hygiene, with a small, known cost. Overstating it invites scope creep; understating it (treating it as a no-op) invites an unplanned regression.