Email Types Bundle Laravel Package

Product Decisions This Supports

• Platform lifecycle planning (the decision this release actually informs). A version bump that adds Symfony 8 / PHP 8.5 support and removes legacy PHP support is a compatibility contract change, not a feature drop. It tells you the package is actively tracking the upstream framework release train, and it forces a decision on your own minimum PHP/Symfony floor.
• Build vs. buy. A maintained integration layer that absorbs upstream framework churn (new major Symfony, new PHP minor) is exactly the kind of glue code you should not own. Every release like this is a data point that the maintenance cost stays with the vendor.
• Roadmap sequencing. If your fleet includes older PHP runtimes, this release is a gate: either you schedule a runtime upgrade, or you pin the prior minor and accept the maintenance debt until you do.
• Use cases it enables. Any Laravel feature that needs to interop with Symfony components (console, HTTP kernel, event dispatcher, serializer, process) benefits from the package tracking Symfony majors early — useful when you plan an early-adopter window on a new PHP release.
• Risk register entry. At v0.x with a major-platform drop mid-minor-series, treat the public API as unstable. Plan for upgrade work per release rather than assuming a stable contract.

When to Consider This Package

Consider it when:

• Your platform is (or is about to be) on PHP 8.5 and/or Symfony 8 — this is the first release that unblocks you.
• You want an integration maintained by someone else rather than copy-pasted bridge code in your own repo.
• Your runtime fleet is already modern; the "legacy PHP removed" clause costs you nothing.
• You are willing to track releases closely and budget a small upgrade task per version while the package is pre-1.0.

Look elsewhere — or pin hard — when:

• You still run legacy PHP versions (pre-8.x per the removal note). This release is a hard stop; stay on the previous minor and plan migration.
• You need a stable API guarantee with long-term support windows; v0.x does not offer that, and a platform-major bump landed without a 1.0 signal.
• You depend on Symfony 6/7 or older Laravel versions that this release no longer targets.
• You need documented deprecation paths — the notes are terse and give no migration guide, so assume manual verification is required.

How to Pitch It (Stakeholders)

For executives: This is a routine but meaningful maintenance release for a Laravel/PHP integration package. It keeps us current with the newest PHP (8.5) and Symfony (8) releases and drops support for old, unsupported PHP versions. The business value is avoided maintenance cost — someone else is absorbing framework upgrade work we would otherwise do ourselves. The cost is a planned platform upgrade if any of our services are still on older PHP. Low spend, low risk, requires a runtime-modernization check before adoption.

For engineering: v0.6.0 is primarily a compatibility release: Symfony 8 support, PHP 8.5 support, and removal of legacy PHP version support. Treat it as a breaking change for our CI matrix and any pinned dependency constraints — audit our minimum PHP version and Symfony constraints before bumping. The package remains pre-1.0, so no backward-compatibility promise should be assumed; pin the version explicitly and re-verify on each release. No new features are described, so there is no user-facing behavior to test beyond a full test-suite run on the upgraded runtime. Recommend: verify minimum-PHP alignment, bump in a branch, run the suite, and only then adopt.