Doctrine Changelog Bundle Laravel Package

Product Decisions This Supports

• Audit & compliance roadmap items. This package gives Symfony/Doctrine services a persisted, queryable per-entity change history (who, what, when, old → new). That is the backbone of GDPR/ HIPAA/ SOX-style audit obligations, customer-support forensics, and "why did this record change" investigations — all without a bespoke subsystem.
• Version history / restore as a product surface. Because it stores prior state, it unlocks "history" panels, restore-to-previous, and soft-undo flows. Scoping this in-house realistically costs 2–6 sprints (diff serialization, collection and relation edge cases, listener wiring, revert semantics) plus permanent ownership of Doctrine edge cases.
• Build vs. buy. Buy unless your need is narrow. The in-house alternative is cheap only for "who last edited these three tables"; it gets expensive fast once "show the full timeline" and "revert" are in scope. But note the framework boundary: this is a Symfony/Doctrine bundle, not a Laravel package. For Laravel/Eloquent services, the correct decision is to adopt owen-it/laravel-auditing or spatie/laravel-activitylog and treat this repo as design prior art — not a dependency.
• Incident response and migration safety. Point-in-time state reconstruction shortens MTTR and makes backfills verifiable — every mutation is diffable, which reduces "can't reproduce it" escalations.
• Roadmap sequencing. History is not recoverable retroactively. If audit/versioning appears anywhere on the roadmap, adopt early; every sprint shipped without it is permanently un-auditable. That is a scheduling decision, not an engineering one.

When to Consider This Package

• Framework fit is the first gate. Adopt as-is only if the stack is Symfony with Doctrine ORM entities. Laravel teams should stop at "reference implementation" and budget a native equivalent instead. Discover this before a spike, not after.
• Consider it when you need entity-level versioning (not just an event log), you want revert-to-version, you can absorb write amplification (one changelog row per mutation) and unbounded table growth, and you accept that the package ships no UI, no retention policy, no analytics layer — those are your build items.
• Look elsewhere when target tables are high-write-volume (bloat and write cost dominate), when audit data must feed a cross-service or streaming pipeline, when you need an immutable/tamper-evident ledger with cryptographic guarantees, or when data changes outside Doctrine (raw SQL, other services, ->update() mass updates).
• Skip entirely when the requirement is narrow — "who last edited these three tables" is cheaper as a trait + listener than as a versioning framework.
• Release-readiness (v5.6.0): the notes are only a compare link — no enumerated features, breaking changes, or deprecations. Treat it as low-signal. Pin the version, read the diff, check PHP/Doctrine/Symfony constraints, and run the suite against a staging copy of the changelog table. Do not let this release trigger an adoption decision in either direction.

How to Pitch It (Stakeholders)

• To executives: "We have an audit/compliance obligation and version-history on the roadmap. This is a maintained open-source component that gives us per-record change history and restore-to-previous out of the box, replacing an estimated multi-sprint internal build. Cost is one extra table and one listener; the change is additive and reversible."
• To engineering: "It's a Doctrine listener that serializes field-level diffs to a changelog table and can revert an entity to a prior version. Low coupling — no domain-model changes beyond mapping config, schema is additive, removal is a config plus migration rollback. Mature 5.x line. Caveat: v5.6.0's notes are effectively empty, so we pin and review the diff rather than auto-bump."
• Disclose the framework mismatch up front. Stating "this is a Symfony bundle, so for our Laravel services we're taking the pattern and using a Laravel-native equivalent" reads as diligence; discovering it after a spike reads as a miss.
• Flag the two operating costs stakeholders will ask about later: storage growth proportional to change volume, and the absence of any retention/archival/redaction policy — secrets are stored verbatim, so a redaction list is a product requirement we own, not a package feature.