Stampie Bundle Laravel Package

Product Decisions This Supports

• Transactional email provider strategy. Stampie abstracts over API-based mail providers (SendGrid, Postmark, Mailgun, Mandrill, and similar) behind one MailerInterface, so the choice of provider becomes a configuration decision rather than an architecture decision. That is the core PM value: it keeps vendor selection reversible.
• Build vs. buy for email plumbing. The alternative to adopting this is writing and maintaining one adapter per provider, per environment. Unless email is your product, that is undifferentiated work — this package is the "buy" (well, "adopt open source") answer.
• Provider migration / failover roadmap. Because the provider is injected, swapping or adding a secondary provider for deliverability or cost reasons is a contained change. Useful when negotiating provider contracts or planning a deliverability contingency.
• Scope check on "we need email features." This package sends via provider APIs. It does not do templating, scheduling, inbound parsing, suppression lists, or analytics — those stay with the provider or a separate tool. It bounds what your team actually builds.
• Upgrade-window planning. This release is a targeted Symfony 5 compatibility fix (stof, PR #50). That is a signal, not a feature: the maintainers are reacting to upstream framework drift, not investing in the package. Treat it as an input to your dependency-lifecycle roadmap rather than a capability change.

When to Consider This Package

Consider it if:

• You are on Symfony (this is stampie-bundle — a Symfony bundle, not a Laravel package; the Laravel/PHP framing needs correcting before it reaches a backlog) in the 4.x/5.x range, and you want a thin, provider-agnostic transactional mail layer.
• You already have Stampie in the codebase and want to keep receiving compatibility patches like this one.
• You need only fire-and-forget API sending — no templating engine, no queue semantics, no bounce handling inside PHP.
• You are comfortable pinning a low-activity dependency and owning the exit plan.

Look elsewhere if:

• You are on Laravel. Laravel's Mail facade plus Symfony Mailer transports (or the provider's own SDK) already covers this ground with first-party support. Adding a Symfony bundle to a Laravel app is friction with no payoff.
• You are on Symfony 6/7 or PHP 8.1+ exclusively. A patch whose headline is "Symfony 5 compatibility" tells you the package is tracking older framework versions. Validate current-version support explicitly before committing; if it isn't there, use Symfony Mailer + provider bridges, which is the maintained path.
• You need active maintenance, security responsiveness, or a support contract. Single-maintainer, release-sparse projects are a poor fit for regulated or high-volume sending.
• Your email requirements are non-trivial — templating, multi-tenant sending domains, deliverability tooling, inbound mail. Buy that from the provider, not from a PHP abstraction layer.
• The patch itself is your only data point. v2.1.1 carries no feature, no API change, no deprecation. It should not, on its own, move a roadmap item.

How to Pitch It (Stakeholders)

To executives: This is a small, free plumbing library that lets us send transactional email through a third-party provider without hard-coding that provider into our product. It reduces switching cost if we ever change email vendors, and it's low-risk to try because it's isolated to the send path. The caveat is maintenance posture — the project is quiet, and this release is only a framework-compatibility fix, so I would not build anything strategic on top of it. Recommendation: adopt only if we're already on Symfony and need provider flexibility; otherwise use the framework's built-in mailer.

To engineering: v2.1.1 is a one-line Symfony 5 compatibility fix — no new API, no breaking changes, no deprecations, safe to take as a routine patch bump. Two things to confirm before we standardize: (1) it's a Symfony bundle, so the Laravel angle in the original request is wrong and needs re-scoping; (2) verify Symfony 6/7 and current PHP support, because the release cadence suggests we'd be adopting a dependency we may have to replace within a release cycle or two. If either check fails, Symfony Mailer with provider transports is the lower-risk default and gives us the same vendor-swap property.

To security/procurement: Single-maintainer open-source dependency, sparse release history, no commercial support. Fine for non-critical transactional mail with a documented exit path; escalate if email is in a compliance or revenue-critical path.