Multi Tenancy Bundle Laravel Package

Product Decisions This Supports

• Multi-tenant and multi-site publishing roadmap: Still informs decisions around tenant-aware routing, domain/subdomain mapping, content isolation, and white-label site provisioning for publishing or CMS-style products.
• Build vs. buy vs. reference: Remains best treated as a reference implementation or code sample, not a production dependency. The new v1.4.0-beta tag softens — but does not overturn — the maintenance concern, so it should not be treated as a committed dependency without a fork/ownership plan.
• Architecture spikes: Useful for evaluating tenant context propagation across request handling, content retrieval, caching, storage, and theming in a PHP publishing stack.
• Risk and licensing decisions: AGPL-3.0 obligations still require legal review, especially for SaaS/network-accessible products. Confirm the license did not change in this release.
• Platform compatibility decisions: This is a Symfony bundle, not a Laravel package. A Laravel product would need a port, adapter layer, or separate implementation — a beta tag does not change that.
• Roadmap prioritization: The project is no longer clearly dormant — upstream shipped a pre-release — but the beta label signals API instability. Treat as "watch and spike," not "adopt."
• Dependency-risk reassessment: The previous "no releases since 2018" signal must be revised; re-baseline on the actual changelog, supported PHP/Symfony versions, and whether this beta is a one-off or the start of a release cadence.

When to Consider This Package

Consider it when:

• You are already working in Superdesk Web Publisher or a Symfony-based publishing stack and need multi-tenant routing/isolation patterns.
• You need a short internal spike or proof of concept to understand tenant resolution, domain mapping, or content isolation.
• You are prepared to fork, own, test, and maintain the code rather than rely on upstream support.
• Legal has approved AGPL-3.0 use for your distribution or SaaS model (verify the license file on the v1.4.0-beta tag).
• You only need architectural inspiration and can extract concepts without taking a hard dependency.
• New: You want to evaluate what changed in v1.4.0-beta before deciding — pin the tag, read the diff, and check supported PHP/Symfony constraints. Note the release notes are currently empty, so the changelog or commit history must be the source of truth.

Look elsewhere when:

• You are building a Laravel application and need a native, maintained multi-tenancy package.
• You need active security support, modern PHP/Laravel compatibility, or a stable release channel — v1.4.0-beta is a pre-release and may carry breaking changes with no documented upgrade path.
• You need full tenant lifecycle features such as provisioning, billing, per-tenant databases, queue isolation, observability, and admin tooling.
• Your organization cannot accept AGPL-3.0 licensing risk.
• You require community validation, documented upgrade paths, or vendor-backed support — a single beta tag with no release notes is not sufficient evidence of sustained maintenance.

How to Pitch It (Stakeholders)

Executive summary: This package remains a low-cost reference point for multi-tenant publishing, not a safe production dependency. Two things changed: upstream shipped a v1.4.0-beta, which means the project is not fully dormant; and the release arrived with no release notes, so scope, breaking changes, and compatibility are unknown. The recommendation stands — use it only for a time-boxed architecture spike or pattern review, not as a committed roadmap dependency.

For engineering: Pin and diff v1.4.0-beta against the last stable tag before drawing conclusions. Verify PHP/Symfony version constraints, license file, test coverage, and whether there is evidence of a release cadence. Do not add it as a Laravel dependency; port only the tenant-resolution and isolation concepts into our own codebase if they prove sound.

For product: It can still help de-risk decisions around multi-site publishing, tenant-aware content, and white-label domains, but a beta with empty notes should not change delivery estimates or become part of the product architecture. Re-evaluate only if a stable release lands with a documented changelog and active maintenance signals.