Service Library Laravel Package

Product Decisions This Supports

• Platform scope decision (Windows deployments): This release re-confirms the package's value only if your product actually ships Laravel/PHP onto Windows hosts — e.g. on-prem enterprise installs, internal tools constrained to Windows Server, or Windows-based CI/agent fleets. It should be a forcing function to answer "do we support Windows as a first-class deployment target?" rather than an incidental dependency.
• Service lifecycle robustness: The new preshutdown behavior (v1.1.0) lets your service signal graceful shutdown before the OS tears it down. That translates directly into a product-quality decision: do we promise "zero lost jobs on reboot/patch cycles"? If yes, this is a concrete implementation lever for that promise (queue drain, in-flight request completion, state flush).
• Build vs. buy on Windows service plumbing: Rolling your own SCM (Service Control Manager) integration is low-differentiation, Windows-specific, and easy to get subtly wrong. This package is the "buy" side of that decision and should be evaluated against a small wrapper around win32service rather than against a full framework.
• Roadmap signal for observability: Preshutdown + rewritten docs suggest a maintainer actively hardening the runtime contract. If Windows is on your 2–3 quarter roadmap, budget a spike now; if it's not, this package should not appear in any dependency manifest.
• Support/ops decision: A rewrite of documentation (PR #13) reduces onboarding cost for whoever owns the Windows deployment runbook — relevant to staffing and on-call planning decisions, not just code.

When to Consider This Package

Consider adoption when:

• Your application must run as a native Windows Service (not a console process kept alive by Task Scheduler or NSSM).
• You need graceful shutdown semantics — draining queues, finishing in-flight work, flushing buffers on service stop or OS shutdown. The v1.1.0 preshutdown support is the headline reason to take this version over v1.0.2.
• You want a thin, dependency-light abstraction over the win32service PHP extension, and your team is comfortable with the extension's install/configuration burden (it is not a Composer-only install).
• You are standardizing service lifecycle behavior across multiple PHP processes/agents on the same Windows host.
• You need a documented, maintained reference for how your services should be structured — the docs rewrite materially lowers the cost of evaluating this in a timeboxed spike.

Look elsewhere when:

• Your deployment target is Linux/macOS only. This is not a Laravel package; it is a Windows service library. Laravel's ecosystem answer for long-running processes is Horizon/Supervisor/Octane on Linux — do not introduce this.
• You need cross-platform service management; you would need a separate Linux story and an abstraction layer above this, which is usually not worth it.
• You require containerized deployment — Windows containers plus PHP service hosting is a narrow, painful path; prefer a scheduler/orchestrator-native supervision model.
• Your failure mode tolerance is low and you need an actively supported, large-community package: this is a small maintainer-led project with a single primary contributor. Have a fallback plan (fork or in-house wrapper) before it becomes load-bearing.
• You only need "run a script periodically" — Task Scheduler or a queue worker is a cheaper answer.

Risk notes to carry into the decision: the "quic add new function signature" change (PR #9) touches an API signature — verify it is additive and not a breaking change for your pinned usage before upgrading; the changelog wording is ambiguous, so treat v1.1.0 as a minor version that still deserves a compatibility check in a staging Windows host.

How to Pitch It (Stakeholders)

For executives: v1.1.0 of our Windows service library adds graceful preshutdown handling and clearer documentation. It is a small, low-cost dependency that only matters if we commit to running the product on Windows Server. If Windows is a target market or an existing customer constraint, this is cheap insurance against data loss during reboots and patching — the kind of failure that generates support tickets and SLA credits rather than feature differentiation. No action is needed if we remain Linux-only; in that case we should explicitly document that Windows hosting is out of scope.

For engineering: This is the win32service/service-library PHP package — a thin layer over the win32service extension for running PHP as a real Windows Service. v1.1.0 adds preshutdown behavior (hook the OS pre-shutdown window to drain work), refreshes tests, and rewrites the docs. Upgrade only if you are on a Windows host; confirm PR #9's "new function signature" is additive against our call sites before bumping, since the changelog is terse. Expectations to set: single-maintainer project, no Laravel integration, non-trivial extension install, and no cross-platform abstraction — treat it as a contained piece of Windows-specific infrastructure with a documented exit path, not as a strategic dependency.