Stampie Bundle Laravel Package

Product Decisions This Supports

• Provider abstraction vs. provider lock-in: Stampie wraps transactional email APIs (Mailgun, SendGrid, Postmark, etc.) behind a common interface, so the underlying product decision it enables is "commit to an email vendor's commercial terms without committing to its API surface." That is a real roadmap decision — it lowers switching cost at renewal or during deliverability incidents.
• Build vs. buy for email infrastructure: It argues for buying the sending provider (deliverability, IP reputation, compliance are not our core competency) while keeping the integration thin. The bundle itself is the "thin integration" layer, not the product.
• Multi-provider failover as a feature bet: If the roadmap includes "transactional email must not go down with one vendor," an abstraction layer is the prerequisite. This is the strongest product justification for the pattern — not the package.
• Feature/use cases it touches: password resets, order confirmations, receipt delivery, account notifications — high-visibility, trust-sensitive flows where a silent provider change is a customer-facing failure, not an internal refactor.
• Important framing caveat: despite the "Laravel/PHP package" label, this is a Symfony bundle, not a Laravel package. Its product value is Symfony DI/config wiring around the stampie/stampie library. For a Laravel roadmap, the correct decision target is Laravel's native Mail transport abstraction, which already delivers the same provider-swap benefit. Evaluate Stampie the library only if you have a framework-agnostic PHP service layer.
• What v2.1.1 changes here: nothing at the product-decision level. It is a single Symfony 5 compatibility fix (PR #50, backported via stof). It does not add providers, does not add failover, and does not touch the Laravel question. It slightly extends the legacy Symfony viability story and nothing else.

When to Consider This Package

Consider only in a narrow, maintenance-shaped case:

• You are already on Symfony (likely an older Symfony version) and already have Stampie in the dependency tree and working.
• You need to keep an existing integration stable while planning migration; you are not adding new sending capability.
• You explicitly want the stampie/stampie library's provider-neutral request/response objects and are willing to own the integration yourself.
• New as of v2.1.1: if your blocker was specifically Symfony 5 compatibility on an existing install, this release removes that one obstacle. Treat it as a stay-of-execution on a legacy service, not as a reason to adopt.

Look elsewhere — decisively — if any of these hold:

• Laravel stack. Use Laravel Mail with a configured transport (or a maintained transport package for your provider). The abstraction you'd be buying is already in the framework; adding a Symfony bundle is framework mismatch for zero incremental value. The v2.1.1 patch does not change this in any way.
• You need a forward-looking maintenance posture. v2.1.1 is a compatibility backport to Symfony 5 — which is itself end-of-life — not a step toward current Symfony (6/7) or current PHP. It signals "keep the lights on," not "actively developed." Confirm the repository's current archival status before relying on it; a single community patch release is not a maintenance commitment, and there is still no published security or support process.
• You need adoption evidence. Zero dependents and ~25 stars indicate no meaningful production validation. There is no community to absorb bugs or backport fixes; one PR from one contributor is not a community.
• You need modern provider SDK coverage. Newer provider API versions and newer vendors simply won't be represented. A Symfony-version fix adds no provider surface.
• You need an SLA or support contract. MIT-licensed, single-maintainer history — you would be the maintainer.

Decision summary for a PM (unchanged): treat this as a pattern reference, not an adoptable dependency. v2.1.1 is a maintenance patch, not a revival: no new features, no new providers, no deprecations, no breaking changes, and no effect on the Laravel decision. If anything, the release is a reminder to re-verify the archive flag we cited previously, because the repo accepted a PR — but "not archived" and "maintained" are different claims, and only the first is now in question. Recommendation stands: do not adopt.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-reviewed henrikbjorn/stampie-bundle following its v2.1.1 release. The release is a one-line compatibility fix for Symfony 5 — no new capability, no new providers, no security process. The strategic picture is unchanged: the underlying idea (protect us from vendor lock-in on a customer-facing channel) is sound, but this specific package targets Symfony rather than our Laravel stack, has no downstream users, and shows maintenance intent limited to keeping an end-of-life Symfony major working. I recommend not adopting it. We already get the same provider-swap capability from Laravel's built-in mail abstraction at no additional cost or risk. Net recommendation: reject, and record the "provider-neutral email" requirement in the architecture notes so it isn't re-litigated. One housekeeping item: our prior note described the repo as archived — the new release suggests that may no longer be accurate, so we should correct the record without changing the decision.

To engineering (short): Do not add this bundle. v2.1.1 fixes Symfony 5 compatibility (PR #50) — that's the entire delta. It does not add providers, does not address Symfony 6/7, and does not change the Laravel story. On Laravel, use the native Mail manager with a configured transport; if we need multi-provider failover, implement it as a transport-level concern there rather than by reintroducing a third-party abstraction. If we discover a legacy Symfony 5 service still using Stampie, this patch may buy it time, but it remains tech debt — open a migration ticket rather than treating the patch as a green light to upgrade or extend. Please also reconcile the repo's current archival status in our dependency register so future reviews start from accurate facts.