Normal Distribution Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged by the release. The 0.5.0 tag does not alter the fundamental mismatch. happyr/normal-distribution-bundle remains a Symfony bundle: a *Bundle class extending Symfony\Component\HttpKernel\Bundle\Bundle, a DependencyInjection extension, and YAML service definitions compiled at Symfony kernel boot. Nothing in the release note signals a move to framework-agnostic packaging, a Laravel service provider, or PSR-11-only wiring. Laravel still has no bundle concept and no compilation pass that will load that class. The reusable asset remains the pure-PHP math underneath the packaging layer.

What the release actually tells us. The release note is a single line pointing at CHANGELOG.md, and the changelog was not included in the review packet. So we know one thing — a tag now exists — and nothing about its contents. Two implications:

• The dormancy claim needs softening, not reversing. The prior assessment's "five years without a release" is now factually stale. A tag means someone still has commit rights and the CI, if any, still runs. That is a real, if small, positive signal about the maintenance floor.
• 0.5.0 is itself a caution. Under semver, a 0.x version means the maintainers are explicitly not promising API stability; a minor bump from 0.4 to 0.5 may contain breaking changes by convention. We are being told the library is pre-stable at the same moment we are being told it is alive.

Integration feasibility. The path table is unchanged in shape; only the verification cost moves.

The new tag does not rescue Path A on its own. Whether it does depends entirely on two lines in the tagged composer.json: the php constraint and the symfony/framework-bundle constraint. If 0.5.0 widened those to PHP 8.x and Symfony 6/7, Path A moves from "will not resolve" to "resolves but still has no Laravel integration." If it did not, the prior verdict stands verbatim.

Technical risk. Three risks from the prior assessment, re-rated against the new signal:

• Maintenance abandonment — downgraded from high to moderate, not cleared. One tag after a long gap is a data point, not a cadence. A single release does not tell us whether the next security-relevant PHP bump will be followed in weeks or years. The single-organisation ownership concern is unchanged.
• Numerical edge cases — unresolved, and now potentially changed. If 0.5.0 touched the erf approximation or tail handling, previously-stated accuracy assumptions may no longer hold. This is the strongest argument for re-running known-value tests against whatever we vendor rather than trusting either version.
• Semantic ambiguity — unchanged, and marginally worse. A pre-1.0 minor bump is precisely the kind of release where argument order, return types, or default parameters get reshuffled. Without the changelog we cannot rule that out.

Evidence caveat. The packet's "data used for the above assessment" field is empty, so the star count, dependent count, and prior release date are carried forward as assertion rather than verified fact. The dependent count in particular is worth a 60-second check: any new dependent appearing after 0.5.0 would be meaningful community validation that did not exist before.

Key questions for the team.

1. What does CHANGELOG.md say for 0.5.0 — specifically, are there BC breaks, and were the PHP/Symfony constraints widened?
2. Does the tag include PHP 8.2/8.3 in its CI matrix, or is that untested?
3. Did the math implementation change, or is this packaging/metadata only?
4. Does the product need a full distribution, or just a z-score lookup and percentile table?
5. Who is the named internal owner if we vendor it?

Integration Approach

Stack fit. The recommendation holds: do not adopt this as a Composer dependency; take the algorithm instead. The 0.5.0 tag makes vendoring marginally more attractive than it was — we can vendor from a current tag rather than a 2020 snapshot, which reduces the "we forked something already stale on day one" objection. It does not make installing a Symfony bundle into Laravel a good idea.

Migration path. Still greenfield. Confirm no existing references (NormalDistribution, Happyr\, bundle registration in config/app.php). If a prior spike left call sites, put them behind a stable interface:

interface Distribution
{
    public function pdf(float $x, float $mean, float $stddev): float;
    public function cdf(float $x, float $mean, float $stddev): float;
    public function inverseCdf(float $p, float $mean, float $stddev): float;
}

Bind in a StatisticsServiceProvider. This insulates us from exactly the 0.x churn the new release signals — if the upstream API shifts again, one file changes.

Compatibility. Target PHP 8.3 and Laravel 11/12. If the 0.5.0 tag widened constraints, note that resolution succeeding is not the same as integration working; the Bundle class still never loads. Do not --ignore-platform-reqs or alias Symfony constraints, regardless of what the new tag permits.

Sequencing. Step 0 is new and cheap:

0. Read the 0.5.0 CHANGELOG.md and the tagged composer.json. Fifteen minutes. This converts the review from "unknown" to "decided" and is the single highest-value action in this document.
1. Requirements and accuracy tolerance agreed with product/data science (half a day).
2. Timeboxed one-hour spike: attempt composer require:^0.5 on the real stack. Concrete evidence, not opinion.
3. Vendor or implement the algorithm; anchor tests on known values — cdf(0) = 0.5, cdf(1.96) ≈ 0.975, pdf(0) ≈ 0.39894 — plus tail cases at z = 3, 4 and invalid σ ≤ 0. Run these against 0.5.0 specifically if it changed the math.
4. Bind behind the interface; add static analysis to CI.
5. If output feeds pricing or risk decisions, ship behind a feature flag with input logging.

Operational Impact

Maintenance. We still become the maintainer under the vendoring path, and the burden remains small: frozen math, handful of functions, a few hours a year. The new release does not change that arithmetic; it only means we should re-sync once at vendoring time and then stop tracking. If we did adopt the dependency, 0.5.0 slightly raises the ongoing tax rather than lowering it — pre-1.0 libraries invite breaking minor bumps, and we would now have to watch a release stream we previously could safely ignore.

Support. No change to the upstream support story. Zero dependents previously meant zero community validation; if 0.5.0 attracted any dependents, that number is worth checking, but one release does not create a support channel. Internal ownership still needs a named engineer, and the statistical contract still belongs in the class docblock: which function is which, what σ = 0 does, behaviour at extreme z.

Scaling. Unchanged and effectively free — pure CPU, no I/O, no state, sub-microsecond per call. Safe in request paths, queued jobs, or row loops. Still worth the sanity check on whether the calculation is a fixed z-score lookup that Postgres or MySQL could do in SQL, making the PHP layer unnecessary.

Failure modes. Ranked by likelihood, with one addition:

• High: Semantics error — PDF where CDF was intended, or mean/stddev transposed. Plausible-looking wrong numbers. Mitigated by interface, typed params, known-value tests.
• High (if adopted as a dependency): Composer resolution breakage on framework upgrade, or a 0.x minor bump silently changing argument order or return type. The 0.5.0 release is a reminder that this stream is unstable by the maintainers' own declaration.
• Medium: DivisionByZeroError / NaN / INF when σ ≤ 0 or inputs are unbounded. Validate at the boundary.
• Medium: Precision loss in the tails under the erf approximation. Re-verify against 0.5.0 rather than assuming the 2020 behaviour carried over.
• Low: Autoload failure after a PHP minor bump.

Ramp-up. Near zero for the mathematics. The real cost is documenting the statistical contract so the next engineer does not reverse-engineer it. One to two days for a mid-level engineer to implement, test, and document — mostly the test suite. markrogoyski/math-php still trades that day for a dependency with a real release cadence and a support story. Either is defensible. Installing a pre-1.0 Symfony bundle into a Laravel application remains the option that is not — a 0.5.0 tag does not change that, and its own version number argues against it.