Stacker Laravel Package

Technical Evaluation

The release is not a release. This is the same 2017 artifact. The 1.0.0 record carries release_published_at: 2017-03-26T09:33:17Z — the exact date the prior assessment recorded as "last release March 2017." These are not two events eight years apart; they are one object, surfacing in the release feed now. What arrived in this cycle is a metadata event — a 2017 tag promoted or re-reported as a release record — not a shipment of code. The empty release notes are consistent with that: a nine-year-old tag promoted into a release object rarely carries a changelog, because no one wrote one.

This invalidates the central premise of the prior assessment. The prior draft reasoned that a 1.0.0 after an eight-year gap "falsifies one specific claim" and shifted the project from known-unmaintained to unknown-maintenance. That inference was wrong, and it was wrong for a process reason worth recording: it compared a release-feed timestamp against a remembered tag date without checking whether they were the same. Rule going forward: before treating a release as an event, compare release_published_at to the tag's commit date. If they match, nothing shipped. A single field would have settled this; its absence nearly reversed a correct recommendation.

Architecture fit. Unchanged and now unambiguously so. Containerized local environments remain the right answer to time-to-first-request and local-vs-CI drift; Stacker remains one implementation among several, and still an implementation whose fitness is determined by base images and Compose definitions frozen in 2017. The optionality the prior draft granted on the strength of "a project willing to cut a major version" is withdrawn — no major version was cut. The third-topology concern (local, CI, production as three independently reconciled environments) stands untouched.

Integration feasibility. Reverted to known-bad, with the same mechanical simplicity on top: clone, populate .env, docker-compose up. The environmental constraints the prior draft suspended — 2017-era pinned PHP images, deprecated Compose syntax, no ARM64 story — are no longer "unknown"; they are the 2017 state, unchanged. The prior draft also flagged that its own figures (359 stars, 0 dependents, March 2017 date) lacked attached registry evidence. That now matters less for the date, which the release payload corroborates at 2017-03-26, and more for the dependents count, which should still be re-pulled before being quoted in a decision document. No Composer distribution path, no devcontainer, no Sail-style wrapper was introduced — there was no release in which to introduce one.

Technical risk. Back to the prior profile, with one item added and one upgraded.

Key questions for the requester.

1. What prompted this review — did someone receive a release notification or a registry alert for 1.0.0? If so, that notification is spurious and the requester should be told so before they act on it.
2. Is anyone in the org currently running Stacker? If yes, they are running nine-year-old images and that is a security item, not an adoption item.
3. What is our current median onboarding time, and what target are we holding this to? (Unchanged, and still the question that should drive the decision.)
4. Which PHP versions, database engines, and extensions must be supported?
5. Is the engineering fleet homogeneous (x86 Linux/Windows) or mixed with Apple Silicon?
6. Who owns developer-environment tooling after adoption, and what is the budget for that ownership?
7. Does our security policy permit 2017-era base images on developer endpoints? (Answer is almost certainly no, which closes the question.)
8. Is the ask "adopt Stacker" or "solve local environment consistency"? Still different answer sets, and only the second one is worth funding.

Integration Approach

Stack fit. Weak. The service topology (nginx → php-fpm → mysql/redis → mail sink) is still a correct design; the 2017 implementation of it is not adoptable as a developer-environment standard in the current cycle. This is a settled finding now, not a pending one.

Options considered.

• Adopt as-is — reject. Nine-year-old base images, deprecated Compose format, no ARM path, no maintainer. This is the recommendation.
• Fork and modernize — technically viable, previously priced as a small platform project (rebuild images, migrate Compose format, add multi-arch, update Xdebug/OPcache, own it forever). Nothing about the 1.0.0 record reduces that estimate, because nothing changed. Only pursue if questions 3–6 produce a compelling case that the topology itself is worth preserving.
• Use as a reference architecture — still the best use of the artifact. Diff its service definitions against our current CI and production definitions and harvest anything still instructive. Zero ongoing obligation.
• Standardize on a current tool — recommended default. Laravel Sail or DDEV give maintained images, multi-arch support, and an upstream whose release cadence we can observe rather than infer.

Migration path and sequencing. The verification gate that opened the prior draft collapses to a half-day confirmation, and the sequence reverts to its original form.

1. Confirm the timestamp reading (30 minutes). Verify against the registry that there is no distinct 1.0.0 commit newer than March 2017. Cheap insurance against being wrong twice in the same direction.
2. Base-image fact sheet (half day). Read the Dockerfiles: PHP version, base image provenance, Compose format, multi-arch presence. Output is a one-page record of why this is rejected, reusable when it surfaces again.
3. Baseline (1 week). Measure current onboarding time, local failure rate, and "works on my machine" ticket volume. This is now the critical-path item, because it is the input to choosing between Sail and DDEV.
4. Tool selection (1 week). Sail vs. DDEV vs. an internal template, evaluated against the baseline from step 3 and the constraints in questions 4–5.
5. Pilot (2–3 weeks). One team, one service, real feature work.
6. Rollout with a deprecation window. Run old and new in parallel; publish a cutover date; retire the old path.

Compatibility. No application-code compatibility surface, and no upgrade-compatibility surface either — there is no newer version to upgrade to. Compatibility work sits entirely in images, Compose format, host OS/architecture, and IDE/debugger integration, and it moves to whichever tool we select rather than to Stacker.

Operational Impact

Maintenance. Settled: there is no upstream maintenance to depend on. A dormant 2017 repository re-reported as 1.0.0 is not a maintainer signalling intent; it is a registry surfacing an old tag. The operational test applies as originally written — can we name an owner and a maintenance allocation? If yes, adoption converts a dead dependency into an internal platform product, which is a strange thing to build on a 2017 foundation when maintained alternatives exist. If no, adoption is not available at all. Either way the answer is the same, and it is no.

Support. Per-developer and front-loaded into onboarding: Docker familiarity, port conflicts, volume permissions, ARM workarounds. On the 2017 images, all of these ticket classes are live, and the ARM class is unresolvable without forking. Expect a short, sharp support bump if anyone in the org acts on the 1.0.0 notification before this assessment reaches them — they will pull 2017 images onto current laptops.

Scaling. Infrastructure scaling is irrelevant; this runs on laptops. Headcount scaling is the dimension that matters: support cost grows linearly with engineer count while tool fitness stays flat. A project with no commits since 2017 has no degradation curve to measure because it has no curve at all. At 10 engineers a bespoke environment is defensible; at 50 it is a tax on every hire, and it is a tax paid in the first week.

Failure modes. Ranked by likelihood of late discovery:

1. Acting on a spurious release notification — the highest-probability failure created by this cycle, and the one just demonstrated in our own review. An engineer or a scan receives 1.0.0, reads it as a modernization, and pulls 2017 images onto a current endpoint.
2. Silent drift — local and CI disagree on a PHP minor or extension; surfaces in staging. Highest cost, lowest visibility, entirely structural.
3. Security findings — endpoint scanning flags EOL base images; remediation means unplanned image work against a repository with no maintainer.
4. Architecture regression — an Apple Silicon hire cannot run the stack, and there is no upstream to file against.
5. Onboarding stall — a new hire loses a day to a broken image pull; no owner to escalate to.
6. Re-surfacing — the same 2017 tag appears in a feed again in eighteen months and consumes another review cycle.

Ramp-up. Low for Docker-literate engineers (hours), steep for everyone else and for anyone on ARM, with documentation quality as the gate. A repository that shipped its final version with an empty changelog has told us what its documentation culture is. Plan to author a runbook for whichever tool we adopt; "read the docs" remains a non-plan.

Recommendation — do not adopt. The prior draft softened this to a conditional hold on the strength of a 1.0.0 release that, on inspection, is the 2017 tag re-reported with a 2017 timestamp. That softening is withdrawn. The original reasoning stands intact: no maintained images, no multi-arch, no upstream cadence, no owner, no documentation — and now with the added confirmation that the last commit predates the current PHP release cycle by the better part of a decade.

Two things follow that are worth more than the decision itself. First, the artifact should be retired from the evaluation queue, not re-reviewed: record the timestamp, record the base-image fact sheet, and route future 1.0.0 notifications for this repository to that record rather than to a new assessment. Second, fix the process that nearly reversed a correct call — a release record whose publish date matches the tag's commit date is a metadata sync, not a shipment, and one field comparison should gate every future release-triggered re-review before any prose is written.

The underlying request — faster onboarding and fewer environment-specific defects — remains sound and worth funding. The next action is to baseline onboarding time and pick between Sail and DDEV on that basis. Stacker is not the vehicle, and the only new information this cycle produced is a reminder that release feeds are not evidence.