Laravel Mail Switcher Laravel Package

Product Decisions This Supports

• Framework upgrade timing (build vs. defer): Release 1.1.0 adds Laravel 9.x and PHP 8.1 support and moves to Laravel's newer mail API (Symfony Mailer, which replaced SwiftMailer in Laravel 9). This is the gating item for any roadmap work that requires upgrading the application stack — the package can now move with the platform rather than block it.
• Build vs. buy for email delivery: The release confirms this is a mail-layer dependency. If the product sends transactional or notification email, the decision is whether to own that plumbing in-house or lean on the package. The fact that the maintainer tracked Laravel's own mail transition is evidence the maintenance burden sits with them, not your team.
• Roadmap ceiling check: Supporting "up to" Laravel 9 / PHP 8.1 is a compatibility floor raise, not a forward commitment. If the product roadmap targets Laravel 10/11/12 or PHP 8.2+, treat this package as a near-term dependency with an open question about its upgrade cadence.
• Use cases it unlocks: teams currently pinned to Laravel 8 because of mail-layer incompatibility can now sequence the Laravel 9 upgrade; projects standardising on PHP 8.1 can adopt without a carve-out.
• Risk/technical-debt register: any custom mail code written against the old SwiftMailer-era conventions can be retired in favour of the package's supported path, reducing bespoke surface area.

When to Consider This Package

• The application is on, or is actively migrating to, Laravel 9.x on PHP 8.1, and email is part of the product surface.
• You want mail behaviour to follow Laravel's own conventions rather than a fork of them — 1.1.0's alignment with Laravel's new mail API is the signal to look for.
• Your team has no appetite to own mail transport, templating, or provider integration as a first-class product concern.
• You need a dependency that has demonstrably survived a major upstream API break (Laravel's mail rewrite), not just one that was written against the old one.

Look elsewhere when:

• The roadmap depends on Laravel 10/11/12 or PHP 8.2+ today — this release does not evidence support beyond 9.x/8.1, and adoption would trade one blocker for another.
• You need a documented support window, LTS commitment, or security-response SLA; release notes alone do not establish that, so verify against the repository's issue/PR activity and commit recency.
• Email is core IP (e.g. deliverability pipelines, complex routing) where vendor control outweighs maintenance savings.
• The package's full feature set, licence, and test coverage have not yet been reviewed — this assessment is drawn from release notes only and should be confirmed before a build-vs-buy call.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on for email has caught up to Laravel 9 and PHP 8.1, and has adopted Laravel's current mail API. That removes a blocker from our platform-upgrade roadmap and reduces the custom code we maintain ourselves. It does not, on its own, get us to the newest Laravel or PHP versions — that remains an open item to track.

For engineering: Version 1.1.0 is a compatibility and modernisation release, not a feature release: Laravel 9.x support, PHP 8.1 support, and migration to Laravel's Symfony Mailer-based email API in place of the legacy approach. Treat it as the green light for the Laravel 9 upgrade path, and as a prompt to delete any remaining SwiftMailer-era custom mail code. Before we standardise, confirm two things the notes don't tell us: whether support extends past Laravel 9 / PHP 8.1, and whether the new mail path is covered by tests.

Recommendation: Adopt if we are on or moving to Laravel 9 / PHP 8.1. Hold and re-assess if our target is Laravel 10+ — in that case this release is a positive signal about maintenance intent but not sufficient evidence of forward compatibility.