Movesms Laravel Package

Product Decisions This Supports

• Runtime/compatibility roadmap: v1.0.0 explicitly targets PHP 8.0 and 8.1. That is a floor, not a ceiling—confirm whether 8.2/8.3 are supported before committing, since both 8.0 (EOL Nov 2023) and 8.1 (EOL Dec 2025) are at or past end-of-life. This is a direct input to your PHP upgrade plan and any security-compliance attestation.
• Build vs. buy: A 1.0.0 tag signals API stability and a maintainer willing to commit to semver. That lowers the cost of "buy" (adopt) versus building in-house, provided the maintainer's bus factor and release cadence check out.
• Feature scope / non-goals: The release note is purely a compatibility statement—no features, no fixes. Treat this as a library that does one thing and deliberately stays narrow. Good for composability; means you should not expect the package to grow into an adjacent problem area.
• Adoption risk scoring: First major version with no history of breaking changes yet. You have zero signal on how the maintainer handles deprecations—budget for that unknown in your dependency-risk register.
• Use cases: Appropriate as an internal or low-blast-radius dependency first; defer customer-facing or revenue-path adoption until you've verified support posture and issue-tracker responsiveness.

When to Consider This Package

• Adopt when: your stack is on PHP 8.0/8.1 (or you've verified 8.2+), the package solves a problem that is genuinely undifferentiated for you, and you can pin the version and absorb a future major bump.
• Adopt with caution when: you are on PHP 8.2+ and compatibility is unconfirmed—require a passing test suite on your target runtime before merge, not just a README claim.
• Look elsewhere when: you need PHP 8.3/8.4 support now, an actively maintained security posture, long-term support guarantees, or a vendor SLA. Single-maintainer packages without a documented release cadence are a poor fit for regulated or high-availability surfaces.
• Disqualifying signals to check: no CI matrix in the repo, no changelog beyond compatibility bumps, stale issues, or no tagged releases between now and your next planning cycle.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose open-source library that has just reached its first stable release (1.0.0). The only thing that release tells us is that it now officially supports PHP 8.0 and 8.1. That's a modest but real signal—1.0.0 implies the API won't churn underneath us. The decision it unblocks is build vs. buy for one narrow piece of functionality: adopting is cheap, and it removes work from our backlog. The open risk is lifecycle—PHP 8.0 is already out of security support—so we should confirm 8.2+ compatibility before it touches anything customer-facing.

To engineering: v1.0.0 is a compatibility tag, not a feature release—no new behavior, no bug fixes. Before we take the dependency, verify three things: (1) the test suite passes on our actual runtime, not just the two versions named; (2) there's a CI matrix so we know what's actually exercised; (3) the maintainer's release cadence and issue-response history. Pin the version, wrap it behind our own interface so a future major bump or replacement is a contained change, and treat it as low-blast-radius until it's proven in a non-critical path.