Product Decisions This Supports
- Build vs. buy for subscription/notification preferences: this package covers polymorphic subscribe/unsubscribe relations, subscription events, and status attachment across models, collections, and pagination payloads. If the roadmap calls for "follow," "watch," "subscribe to topic," or notification-preference mechanics, adopting it removes a multi-sprint build in favor of configuration and thin domain glue.
- Target-version policy for the platform: 5.0.0 requires PHP 8.3+ and Laravel 13.x. This release effectively forces a decision on whether the product rides the newest Laravel line or stays pinned. Teams on Laravel 12 or PHP 8.2 must remain on a 4.x release, which means a known end-of-line for that branch and a planned upgrade window.
- Upgrade sequencing, not scope: the vendor states subscription APIs, events, configuration, and database schema are unchanged, and no migration republishing is required. That makes this a platform-alignment upgrade rather than a feature release — it should be scheduled with PHP/Laravel runtime upgrades, not treated as a separate product initiative.
- Support-matrix commitments: validated on PHP 8.3, 8.4, and 8.5 with both highest and lowest secure dependency sets. This is useful evidence for a stated supported-platform matrix in customer-facing documentation and for security review sign-off.
- Low-risk extensibility bet: the package stays deliberately narrow (subscriptions, events, status decoration). It is a complement to, not a replacement for, billing/subscription-commerce systems — useful for engagement features, not for monetization logic.
When to Consider This Package
Adopt when:
- The product needs many-to-many, polymorphic subscription relationships (users subscribing to tags, threads, authors, channels) with minimal bespoke code.
- The team is already on, or committed to, Laravel 13.x and PHP 8.3+; anything older should stay on 4.x, and that constraint should be explicit in the adoption decision.
- You want subscription state surfaced efficiently in list and paginated API responses (the release notes call out status attachment across models, collections, and pagination inputs) rather than issuing per-item queries.
- The requirement is engagement-level subscribe/follow semantics with events for downstream notification or feed fan-out.
Look elsewhere when:
- The domain is paid subscriptions, plans, proration, invoicing, or entitlements — that is billing territory (Cashier, Stripe, or a dedicated billing service), and forcing this package into that role will create rework.
- The organization cannot move to Laravel 13 / PHP 8.3 in the near term and needs an actively developed branch; a 4.x pin means accepting a maintenance tail.
- You need guaranteed semantic-versioning stability with a long support horizon or a commercial SLA. This is a single-maintainer open-source package; the 5.0.0 major bump with a modest 20-test/106-assertion suite is honest and passing, but it is not an enterprise support contract.
- Scale requirements demand a normalized, high-volume subscription store with its own sharding/read-model strategy — in that case implement the model directly against your own schema.
How to Pitch It (Stakeholders)
To executives: This is a small, well-scoped open-source Laravel package that gives us subscribe/follow/watch functionality without building it ourselves. The new 5.0.0 release is a compatibility release, not a feature release — it moves the package onto PHP 8.3+ and Laravel 13.x. Critically, it does not change the data model, the API surface, or require database migrations, so the upgrade risk is low and the cost is bounded to our own runtime upgrade. The decision it forces is a platform one: we choose when to move to Laravel 13, and until then we stay on the 4.x line. It is not a billing system and should not be positioned as one.
To engineering: 5.0.0 requires PHP 8.3+ and Laravel 13.x; read UPGRADING.md before bumping. No schema changes, no migration republishing, and existing APIs/events/config are preserved, so the diff should be dependency and CI work. Validation covers PHP 8.3–8.5 on highest and lowest secure dependencies, with 20 tests / 106 assertions, Pint, Composer validation, platform checks, and dependency audits all green — thin but honest coverage for a package of this size, so we should add our own integration tests around the subscription flows we depend on. Plan the bump alongside our Laravel 13 upgrade, pin the version explicitly, and keep a 4.x fallback path documented in case the runtime move slips.