Ezpublish Kernel Laravel Package

Product Decisions This Supports

• Legacy platform continuity, not greenfield feature work. se7enxweb/ezpublish-kernel is a community-maintained fork of the eZ Platform 2.5 LTS kernel (Symfony-based, PHP 7.x era) — not a Laravel package. The PM decision it informs is "how long do we keep our eZ-based CMS estate alive, and at what cost," rather than "which Laravel feature do we build next."
• v7.5.40 is a maintenance bump, not a capability release. The changelog link shows a patch-level delta from v7.5.39 with no documented features, deprecations, or breaking changes in the release body. Treat it as a security/stability pin candidate; do not plan roadmap work around it.
• Build vs. buy vs. migrate. Each kernel patch release is a forcing function on the real decision: continue consuming community patches, fund in-house maintenance of a pinned fork, or budget a platform migration off eZ/ Ibexa. The release cadence itself is the signal — steady patch output indicates the fork is still breathing; silence is the cue to accelerate migration planning.
• Release-gating and support-window policy. Adopting v7.5.40 (or deferring it) sets precedent for your patch SLAs on an upstream-EOL codebase, and defines what "supported" means for internal stakeholders consuming CMS-backed product surfaces.
• Use cases supported in-product: content-driven marketing sites, editorial workflows, multi-language content delivery, and legacy integrations still bound to the eZ content model — all of which remain viable on this kernel, but none of which should be positioned as strategically forward-looking.

When to Consider This Package

Consider it when:

• You already run an eZ Platform 2.5-era stack and need a maintained kernel source after upstream end-of-life.
• You need an actively tagged patch stream (v7.5.39 → v7.5.40 and onward) to satisfy internal vulnerability-remediation or change-control policies.
• Your team has Symfony 3.4/4.x and legacy eZ bundle expertise, or a partner who does.
• The migration horizon is 12–24 months and you need a bridge, not a destination.

Look elsewhere when:

• You are starting anything new. This is not the foundation for a new build, and it is not a Laravel package — do not evaluate it against Laravel's ecosystem, service container, or package conventions.
• You need PHP 8.2+, modern Symfony, or long-term vendor support commitments.
• The requirement is headless content delivery or API-first content modeling — Ibexa DXP (the successor line) or a modern headless CMS is the correct comparison, not this fork.
• You cannot absorb the operational risk of a single-maintainer community fork, or you need CVE response times backed by an SLA.

Before adopting v7.5.40 specifically: read the actual compare diff at the linked GitHub URL. Patch-level releases in this line are typically dependency bumps and minor bug fixes, but the release body documents nothing — verify no transitive dependency or PHP-version constraint changes before bumping.

How to Pitch It (Stakeholders)

For executives: This is a routine patch to the CMS kernel behind our existing content platform, published as v7.5.40. It adds no new capability and changes no product surface — its only value is keeping a legacy system patched and defensible in audit. The strategic point is not the release; it's that we are running a community fork of an end-of-life platform, and every patch cycle is a reminder that our maintenance cost curve is flat-to-rising while our feature velocity on this stack is effectively zero. Recommendation: approve the patch as low-risk hygiene, and separately fund a migration options paper with a decision date.

For engineering: Vendor in v7.5.40 as a patch pin behind your existing regression suite; confirm the compare diff contains no PHP or Symfony version-constraint changes before merging. Do not refactor against this kernel — treat it as frozen. Log any upstream deprecations you encounter as migration inputs, not as work items. If the fork's release cadence stalls for more than two cycles, escalate: that is our trigger to move from "maintain" to "exit."

For product: No roadmap impact. Do not scope features that depend on kernel-level changes here; if a requirement needs one, that is a signal the requirement belongs on the migration target, not on this stack.