Artisan Io Laravel Package

Product Decisions This Supports

• Framework lifecycle and upgrade planning. The only signal in v3.0.0 is a platform-support change — adding Laravel 7/8 and dropping Laravel 5. That makes this release a compatibility milestone, not a feature release, and it should be evaluated primarily as an input to your Laravel upgrade roadmap rather than as new product capability.
• Version-pinning and dependency-risk decisions. A v3.0.0 whose ceiling is Laravel 8 implies the package is not tracking current Laravel majors. Any decision to adopt it now is effectively a decision to freeze that part of the stack at Laravel 7/8 until the maintainer ships further support — treat this as a scheduling constraint on your upgrade work, not just a composer constraint.
• Build vs. buy. If your product is already on or moving to Laravel 9+, the honest default is buy-and-fork or build: budget for maintaining a fork, or for replacing the package with first-party code or an actively maintained alternative. If you are staying on 7/8 for the foreseeable future, buying (adopting) is fine and cheap.
• Legacy-app triage. This is a useful dependency for maintaining existing Laravel 7/8 applications through their end-of-life window — e.g. keeping a mature product in security-patch mode while new investment goes elsewhere.
• Not a differentiator. Nothing here supports feature, pricing, or go-to-market decisions. Do not let a compatibility bump appear on a roadmap as delivered value.

When to Consider This Package

Adopt — or keep — it when:

• Your application is on Laravel 7 or 8 and will remain there for the duration of the next planning cycle.
• You are already on Laravel 6 or below and this package is a prerequisite for a stepwise framework upgrade; v3.0.0 is a deliberate forcing function to get you off Laravel 5.
• The package's functionality is genuinely non-core and cheap to replace, so the coupling risk is acceptable.
• You need a working dependency today and can tolerate a maintainer who lags the framework's release cadence.

Look elsewhere — or plan to fork/vendor — when:

• Your stack is Laravel 9 or later, or your roadmap commits to getting there within the next 12 months. v3.0.0 gives you no path.
• The package sits on a critical path (auth, payments, data access, queueing) where an unmaintained dependency becomes an incident, not an inconvenience.
• You require a published support policy, security-response commitment, or LTS alignment. Dropping Laravel 5 without a deprecation runway in the notes is a mild governance yellow flag — confirm there was a prior deprecation announcement.
• You are making a multi-year architectural bet. Support that tops out at Laravel 8 signals a maintenance cadence you should price into total cost of ownership.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release is a maintenance update, not a new capability. It keeps the package usable on Laravel 7 and 8 and formally ends support for Laravel 5. The material fact is not what it adds but what it reveals: the package's support ceiling is Laravel 8, while current Laravel releases are several majors ahead. That does not block us today, but it constrains our upgrade timeline and creates a known dependency risk we should track and fund — either by scheduling a replacement or by accepting a deliberate freeze of this component.

For engineering (the operational summary): v3.0.0 is a breaking change for anyone on Laravel 5 — do not take this as a patch bump. Composer constraints must be checked before merge. On Laravel 7/8, upgrade is low-risk and recommended for security patching. On Laravel 9+, this package is a blocker: document the fork cost or the replacement candidate before the next framework upgrade planning cycle, and do not silently pin the whole application's Laravel version to satisfy one dependency.

Ask: Treat this as a tracked dependency risk with an owner and a review date, not as a feature delivery.