Acme Bundle Laravel Package

Product Decisions This Supports

• Support-window and version-portability strategy: Release 4.0 ships a documented pattern for keeping one bundle backward- and forward-compatible across framework versions — override getPath() with a Kernel::VERSION_ID check and expose legacy locations through Resources/ symlinks (config, public, translations, views). For a PM this is a support-cost lever, not a feature: it lets you promise a longer support window without forking the codebase or maintaining parallel release lines.
• Build vs. buy / maintain vs. rewrite: If your product ships a bundle, plugin, or SDK that downstream teams consume, the symlink-plus-getPath() approach is a cheap, self-hosted compatibility shim. Compare its ongoing cost against maintaining two release trains. For most teams this favors "maintain one line" — but it does introduce path indirection that must be tested and documented.
• Roadmap sequencing: 4.0 is best treated as an upgrade-enabler release, not a marketing milestone. It unblocks a "dual-track support" roadmap item (old + new framework majors simultaneously) and should be scheduled alongside, not instead of, customer-facing work.
• Use cases it unlocks: internal package/plugin marketplaces, customer-facing add-ons with LTS commitments, multi-tenant deployments where different tenants run different framework majors, and partner integrations that cannot be force-upgraded on your cadence.
• Caveat for prioritization: the release notes describe Symfony-style bundle internals (Bundle, Kernel::VERSION_ID, Resources/ layout) rather than Laravel-specific conventions. Before committing roadmap capacity, confirm whether your target package is genuinely Laravel-native or is a framework-agnostic/Symfony-lineage bundle whose guidance needs adapting (service providers, config/ publishing, views namespacing).

When to Consider This Package

Adopt it when:

• You ship a package/bundle consumed by applications pinned to more than one framework major version, and you cannot force consumers to upgrade on your schedule.
• You have explicit LTS or backward-compatibility obligations in contracts, SLAs, or a published support matrix.
• Your CI, Composer packaging, and deployment tooling preserve symlinks (Docker build contexts, archives, and some Windows/zip workflows do not) — validate this before adopting the Resources/ symlink layout.
• You can absorb the documentation and onboarding cost of explaining why paths differ by installed version, and you have a place to document the mixed branch/pattern.

Look elsewhere or defer when:

• You target a single, current framework version — the symlink indirection and version-branching getPath() add cognitive overhead with zero payoff.
• Your distribution channel cannot reliably carry symlinks, or your team is not prepared to support two layout conventions.
• You need customer-visible features; 4.0 is compatibility scaffolding, so do not staff it as a feature release.
• The codebase is Laravel-native only and the Symfony bundle guidance does not map cleanly — in that case evaluate the analogous Laravel mechanism (package config/asset publishing, namespaced views) rather than copying this recipe verbatim.

How to Pitch It (Stakeholders)

For executives: Version 4.0 is a support-cost release, not a feature release. It gives us a single codebase that runs on both older and newer framework versions, which means we can keep existing customers on their current stack while new customers adopt the latest — without doubling maintenance or forking the product. The main trade-off is small, contained engineering overhead and a stricter packaging/CI requirement. Recommendation: fund it as a maintenance item tied to our support-window commitment, not as a roadmap headline.

For engineering: 4.0 documents a concrete compatibility pattern: override getPath() to return the parent directory when Kernel::VERSION_ID >= 40400 and the bundle directory otherwise, and expose config/, public/, translations/, and views/ to the legacy location via symlinks under src/Resources/. Expect to own (a) a version check in the bundle entry point, (b) a build/packaging path that preserves symlinks, and (c) tests that exercise both layouts. The upstream mixed branch is the reference implementation. Verify the pattern maps to our framework target — the notes are written against Symfony bundle conventions — and document the mapping before rollout.