Version Checker Laravel Package

Product Decisions This Supports

• Feature Development: Enables proactive version compatibility checks for RoadRunner-based applications, reducing runtime errors from mismatched dependencies.
• Roadmap Alignment: Supports a "shift-left" approach by integrating version validation into CI/CD pipelines (e.g., pre-deployment checks).
• Build vs. Buy: Avoids reinventing version-checking logic, leveraging a lightweight, MIT-licensed solution instead of custom scripts. The v1.4.0 rename to roadrunner/version-checker signals the package is being consolidated under the official RoadRunner vendor namespace — a stronger buy signal (first-party stewardship, less "abandoned third-party" risk).
• Use Cases:
  • Microservices: Validate RoadRunner versions across distributed services.
  • Legacy Migration: Ensure backward compatibility during upgrades — including the package's own v1.3 → v1.4 namespace migration.
  • SaaS Multi-Tenancy: Verify tenant-specific RoadRunner versions in shared environments.

When to Consider This Package

• Adopt if:
  • Your app relies on RoadRunner and needs deterministic version checks (e.g., for critical workflows).
  • You’re using CI/CD and want to fail fast on version mismatches (e.g., GitHub Actions, GitLab CI).
  • Your team lacks bandwidth to maintain custom version-checking logic.
  • You are starting fresh or can schedule a Composer rename — v1.4.0 changes the package identity from roadrunner-php/version-checker to roadrunner/version-checker. New adopters should depend on the new name directly.
• Look elsewhere if:
  • You need broader language support (this is PHP-only).
  • Your versioning requirements exceed RoadRunner-specific checks (e.g., multi-package dependency trees).
  • You’re already using a comprehensive dependency manager (e.g., Composer’s built-in checks).
  • You cannot absorb a package-rename migration right now — treat v1.3.x as a short-lived holding position, not a long-term pin.

How to Pitch It (Stakeholders)

For Executives: "This package automates RoadRunner version validation, reducing deployment failures by catching incompatibilities early. For example, if a microservice upgrade breaks a shared RoadRunner instance, we’ll detect it in CI—not production. v1.4.0 moves it under the official roadrunner/ vendor namespace, which lowers our dependency-risk profile. Minimal overhead (MIT license) with high ROI for stability."

For Engineering: "A single Composer dependency adds proactive version checks for RoadRunner. Use it in composer.json scripts or CI hooks to fail builds on mismatches. Heads-up on v1.4.0: the package was renamed to roadrunner/version-checker — plan a composer remove / composer require swap plus a lockfile refresh rather than an in-place composer update. No runtime impact, and it aligns with our shift-left testing goals."