Product Decisions This Supports
- Build vs. buy for content delivery. This package supplies a ready-made delivery route plus the plumbing (prune command, publishables) that would otherwise be hand-built on top of Statamic. That makes "adopt and configure" a credible alternative to a custom delivery endpoint in the roadmap, at least for v0.1.x-scale needs.
- Publishing/retention roadmap. The bundled prune command points at a lifecycle concern — stale delivered artifacts accumulating over time. If content freshness or storage growth is on the roadmap, this is a candidate building block rather than a from-scratch work item.
- Operational packaging decisions. Publishables mean config/assets ship with the addon, which affects how we template new environments and how much setup we push onto platform/DevOps versus application code.
- Release-management policy for early-stage dependencies. v0.1.1 is a patch that fixes a double-registration defect in the service provider. It's a signal to set (or reaffirm) a policy of pinning pre-1.0 packages and reviewing each release rather than floating constraints.
- Not a differentiator. Nothing here changes positioning or customer-facing scope; treat it as dependency hygiene, not a feature input to quarterly planning.
When to Consider This Package
Consider it when:
- The product is already a Statamic site (Laravel-based) and the team wants delivery behavior wired in through the standard
AddonServiceProvider lifecycle instead of bespoke bootstrapping.
- You need a delivery endpoint as part of the CMS surface, and are comfortable with the addon owning that route.
- You want scheduled/command-driven cleanup of delivered content, and prefer a maintained command over an in-house artisan command.
- The team accepts pre-1.0 semantics: patch releases may still correct structural issues like provider boot ordering.
Look elsewhere when:
- The stack isn't Statamic — the value is entirely in hooking
bootAddon() and the Statamic provider lifecycle; on plain Laravel you'd be paying for indirection.
- You require a stable 1.0+ API contract, published support windows, or an SLA — v0.1.x with bugfix-only releases doesn't provide that assurance.
- You need a full headless/API content platform with auth, versioning, and rate-limiting guarantees; evaluate Statamic's own API surface or a dedicated CMS before assuming this addon covers it.
- The delivery route, command, and publishables are the only things you need — the surface area is small enough that in-house code may cost less than a dependency review and an ongoing upgrade obligation.
How to Pitch It (Stakeholders)
To executives: This is a small, narrowly scoped addon for our Statamic-based stack that gives us a content delivery route, a cleanup command, and packaged config out of the box. The v0.1.1 release is a maintenance fix — no new capability, no breaking change, no migration work. Risk is low and contained: we pin the version and review each release until it reaches 1.0. The decision it informs is build-versus-adopt for content delivery, and adopting keeps that off the engineering critical path. It is not a customer-visible change and shouldn't move roadmap dates.
To engineering: v0.1.1 corrects a real defect. The provider previously overrode Statamic's bootRoutes(), bootCommands(), and bootPublishables(), but AddonServiceProvider::boot() already invokes those before bootAddon() — so the delivery route, the prune command, and the publishables were each registered twice. Practical impact: duplicate route entries and, more importantly, a prune command that could be registered (and therefore invoked) twice, plus duplicate publish tags. The fix is to stop overriding and let the parent boot handle it. Action: bump the pin, confirm route:list shows a single delivery route, confirm the prune command appears once in artisan list, and spot-check the publish tags in a staging deploy. No config or data migration expected. Because this is a patch on a 0.1.x line, keep the version constraint exact rather than caret-ranged, and add the route/command registration checks to our upgrade checklist so the next provider-level change is caught cheaply.