Pomm Foundation Bundle Laravel Package

Technical Evaluation

Architecture fit: poor for a Laravel stack — unchanged, and still the gating finding. v0.7.0 is a dependency-constraint bump only: PHP floor raised to 8.0, Symfony constraints raised to 6. Neither change touches the packaging model. gnugat/pomm-foundation-bundle remains a Symfony bundle — a Bundle subclass, a DependencyInjection extension, YAML under a pomm: key — with no Illuminate\Support\ServiceProvider, no facade, no config publisher, and no config/*.php contract. The two options are unchanged: (a) stand up Symfony DI/HttpKernel machinery inside a Laravel app purely to boot it, or (b) skip the bundle and hand-wire PommProject\Foundation\Pomm. Option (b) is still the only defensible path, and it still means the package under evaluation contributes nothing — the real dependency is pomm-project/foundation, with this repo as a configuration reference. A version bump does not move this finding by a single point.

Integration feasibility: low, but one previously blocking gate now opens. The underlying library is still a PostgreSQL-only object mapper with its own conventions — session pools, a ModelManager registry, flexible entities without an identity map or lazy loading, a bespoke Where DSL. Nothing in Laravel's data layer carries over: no Eloquent relationships, no DB::transaction hooks, no query event listeners, no RefreshDatabase, no Telescope or Pulse instrumentation. What did change is installability: the previous evaluation flagged a likely hard stop at composer resolution against a current Laravel 10/11 runtime. With PHP 8.0+ and Symfony 6, that stop is probably gone. The feasibility verdict is unchanged, but the reason shifts from "cannot install" to "installs, then costs a full data-layer rewrite." The second is a worse conversation to have late.

Technical risk: high, with the dependency-resolution component downgraded and everything else intact.

• Version-constraint risk: materially reduced. The PHP 8.0 / Symfony 6 bump plausibly clears the composer gate on Laravel 9/10/11. Treat as probable, not confirmed — the constraint ranges and the pinned pomm-project/foundation version are not in the release notes and must be read from composer.json directly.
• PHP 8.0 floor is a weak signal, not a strong one. PHP 8.0 reached end of life in late 2023. Declaring it as the minimum means the maintainer is willing to support EOL runtimes — good for install flexibility, neutral-to-negative as evidence of active maintenance discipline. Verify the CI matrix actually exercises 8.3/8.4.
• Symfony 6 is a wide tent. If the constraint is ^6.0, it resolves to 6.4 LTS (fine) but also permits 6.0–6.2, all EOL. Confirm whether ^7.0 is supported or the ceiling is hard at 6.
• Ecosystem signal remains effectively zero. No dependents were added by this release. A constraint bump does not create a troubleshooting corpus, a patch pipeline, or a second maintainer. Bus factor is still one.
• Cadence uncertainty replaces staleness. The prior assessment cited a 2022-02-28 last release. That specific objection is now retired — but a single release after a multi-year gap is a data point, not a cadence. Do not let one compatibility bump be read internally as "actively maintained."
• Underlying project health: unverified and unchanged by this release. This repo's bump says nothing about pomm-project/foundation's own release activity, security posture, or composer audit coverage. That dependency is where the actual query execution lives.

Key questions to resolve before spending engineering time:

1. Is the target application actually Laravel, or is "Laravel" shorthand for "PHP app"? Unchanged and still the first question. If any meaningful share of the backend is Symfony, this evaluation flips toward "plausible." v0.7.0 is precisely the release that makes the Symfony branch viable again.
2. Does the team need Pomm's PostgreSQL-native access (arrays, hstore, jsonb operators, RETURNING, custom types) badly enough to forgo Eloquent? If not, the premise still collapses regardless of version constraints.
3. Partially answered: PHP 8.0+ / Symfony 6 should resolve against a current lockfile. Confirm by reading the actual constraint strings rather than the release-note prose, and confirm no --ignore-platform-reqs is required.
4. Partially answered, but a new question replaces it: which pomm-project/foundation version does v0.7.0 pin, and is that version itself current and patched?
5. Who patches this if a CVE lands in the query builder or connection layer? Still us. The bump demonstrates the maintainer can merge a composer change; it does not demonstrate a security response capability.
6. Was v0.7.0 accompanied by any CI modernization (PHP 8.3/8.4 in the matrix, static analysis, dependency auditing), or is it a two-line composer edit? The answer determines whether the next PHP or Symfony major is a 2029 problem or a 2026 one.

Integration Approach

Stack fit: still not a fit for a Laravel-first team. The evaluation score of 0.06 reflected a thin, single-purpose adapter with no adoption. v0.7.0 does not add features, dependents, or Laravel affordances. A Laravel-first team should still record a no — but the memo now needs a sharper rationale, because "it won't install" is no longer available as the shorthand. The correct reason is the Symfony/Laravel packaging mismatch plus a full data-layer rewrite, not version rot.

If the stack is genuinely Symfony + PostgreSQL, this release changes the answer. It moves from "unmaintained, fork-before-use" to "plausible, with a thin maintenance hedge." Symfony 6 support means it works on a currently supported major without constraint surgery. The bundle's value is config shape and service wiring — pooled sessions, a ModelManager service, profiler integration. Forking is no longer a day-one prerequisite; it remains a contingency to budget for at the next Symfony major.

Migration path from Eloquent or Doctrine DBAL is still a rewrite, not a swap. No bridge, no dual-write, no schema introspection overlap. Concretely:

• Keep Laravel's own migration tooling. Pomm has no schema-diff or migration story equivalent to php artisan migrate; do not cede schema ownership.
• Introduce Pomm behind existing repository interfaces, one bounded context at a time, with the interface as the seam.
• Accept that any read model relying on Eloquent eager loading must be re-expressed as explicit joins or Where composition.

Compatibility gates, reordered because the first two now likely pass: PHP version support → Symfony component constraint resolution → confirm pinned pomm-project/foundation version and its patch status → PostgreSQL server version and driver (ext-pdo_pgsql / ext-pgsql) → connection/session semantics under our deployment topology (FPM vs. Octane). The gating failure has moved downstream to session semantics under long-lived workers — which is harder to detect in a spike than a composer conflict.

Sequencing for a Laravel shop, if leadership insists on evaluation: (1) timeboxed spike — one afternoon, no production code — install resolution plus a single query round-trip; the install half is now likely to succeed, so budget the time for the query and transaction half; (2) written go/no-go against Eloquent feature parity for the target domain; (3) if go, scope Pomm to a single read-heavy, PostgreSQL-feature-dependent context. Do not expand the spike's scope on the strength of a version bump — the integration cost profile is identical to the pre-0.7.0 assessment.

Operational Impact

Maintenance: still our problem, slightly deferred. With one maintainer and one release after a multi-year gap, assume we own patching, constraint widening, and PHP/Symfony compatibility going forward. What v0.7.0 buys is time — the next forced fork is plausibly a Symfony 7/8 or PHP 9 event rather than an imminent one. Budget accordingly: a small standing tax, not an emergency.

Support: no vendor, no community. Unchanged. No paid support, no active issue triage, no Stack Overflow corpus. On-call engineers will debug the query builder from source. The 0.7.0 release does not add a single answerable search result.

Scaling: the connection model remains the sharp edge, and it is the risk this release did not touch. Pomm's session pools are PHP object pools, not true database connection pools. Under PHP-FPM this is roughly benign; under long-lived workers (Octane, Swoole, RoadRunner) stale sessions and accumulated state are a realistic leak vector. Persistent-worker deployment should be treated as an explicit incompatibility to validate, not an assumption. Throughput ceiling is PostgreSQL's, not Pomm's — the library is thin enough not to be the bottleneck, and equally will not help.

Failure modes to instrument for (one retired, one added):

• Deploy-time resolver conflict — largely retired by the PHP 8.0 / Symfony 6 bump. Retain as a lower-probability alert on the next major.
• Cadence misread (new) — a compatibility bump interpreted internally as "actively maintained," leading to an adoption decision made on the release note rather than on the dependency's actual health. Counter this in writing before the news circulates.
• Transaction boundary drift — code expecting DB::transaction semantics but receiving Pomm-managed sessions; partial commits under nested logic are plausible and hard to reproduce.
• Observability blind spots — no automatic query logging, no slow-query attribution, no N+1 detection. Dashboards will show an opaque gap wherever Pomm handles traffic.
• Test-harness gaps — no RefreshDatabase equivalent; fixture isolation must be built and owned by us.
• Abandonment — a CVE or a PHP major break with no upstream fix and no fork budget allocated. Probability edged down; blast radius unchanged.

Ramp-up: steep relative to the payoff, unchanged. Every engineer must learn a second, idiosyncratic data-access idiom with no transferable skills back to Eloquent or Doctrine, and no documentation ecosystem to lean on. For a library whose only differentiated capability is PostgreSQL-native querying, a team is still better served by Eloquent's raw-expression support or a scoped DB::select layer.

Recommendation: no-go for the Laravel target — held, with a narrowed margin. v0.7.0 is a genuine improvement to installability and removes the stalest objection in the prior assessment. It does not touch the primary blocker: this is a Symfony bundle with no Laravel integration surface. Document the decision and the current reasons — packaging mismatch, full rewrite cost, single maintainer — rather than the retired version-constraint argument, so the memo survives the next release. Revisit conditions: the stack gains a real Symfony component, or PostgreSQL-specific capability becomes a hard product requirement that Eloquent demonstrably cannot meet. In the Symfony case, upgrade the verdict from no-go to a scoped spike; in the Laravel case, the answer is unchanged.