Timeline Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for activity timelines. If a roadmap item calls for a user-facing or admin-facing activity stream ("who did what, when" — comments, status changes, audit trail, notifications feed), this package represents one concrete implementation pattern: a Sonata-admin-integrated timeline backed by SpyTimelineBundle's event/action model. It's useful as prior art when writing the spec, not as a runtime dependency.
• Build vs. buy vs. borrow. The package sits in the "borrow" column — it's a thin integration layer between two Symfony bundles rather than a product in its own right. Evaluating it forces the team to explicitly choose between (a) rolling a timeline feature in-house, (b) adopting a maintained feed/activity library, or (c) copying the data model from an archived integration.
• Stack standardization. It implicitly answers "are we a Sonata shop?" If the answer is no — and especially if the backend is Laravel — this package is out of scope by construction. It's a Symfony/Sonata bundle, not a Laravel package, and any roadmap decision that assumes otherwise needs correcting early.
• Audit/compliance timeline requirements. The underlying concept (persisting timeline events against entities) maps to audit-log requirements. Reviewing this package helps PMs separate "audit log" (compliance, immutable, queryable) from "activity feed" (social, presentational) before committing engineering effort.
• Technical-debt triage. With zero stars, zero dependents, and archived status, it's a data point in dependency-health reviews: it should not be added to a dependency manifest, and if it already appears in one, that's a migration ticket.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining a legacy Symfony 2.x/3.x application already running Sonata Admin and already running SpyTimelineBundle.
• You need a timeline/activity feed surfaced inside Sonata's admin UI with minimal custom code.
• The codebase is in maintenance mode: no new PHP version upgrades planned, no security-sensitive exposure of the timeline data, and no expectation of upstream fixes.
• You are treating it as a reading reference — a source of design ideas for entity-to-timeline wiring — rather than as an installed dependency.

Look elsewhere if any of these are true:

• The project is Laravel, or any non-Symfony framework. The package is structurally irrelevant; it cannot be installed or meaningfully ported without rewriting it.
• You are starting a new build. Archival means no security patches, no PHP 8+ compatibility work, and no bug fixes. Adopting archived code in a new product is a roadmap risk you'd have to justify to engineering leadership and likely fail to.
• You need an actively maintained activity-feed or audit-log capability — evaluate current, supported libraries (or a small in-house event table with an index on (subject_type, subject_id, created_at)), which is generally cheaper than resurrecting an abandoned bridge.
• You require vendor support, a security review trail, or an SLA.
• You need rich timeline semantics (aggregation, fan-out, per-viewer filtering). This integration layer does not provide those; it delegates to SpyTimelineBundle, which is itself the thing you'd need to vet.

Practical guidance: the package's only durable value is as a reference implementation of how Sonata bundles wire third-party services into the admin panel. Read it; don't require it.

How to Pitch It (Stakeholders)

For executives: This is an archived, zero-adoption integration bundle with no maintainer. It is not a candidate for adoption in any active product, and it is not a Laravel package despite being filed alongside PHP/Laravel tooling — it targets Symfony/Sonata. Recommendation: no investment. If a timeline or activity-feed capability is on the roadmap, treat it as a fresh scoping exercise with a maintained or in-house solution; the cost of that work is modest, and it avoids the standing risk of shipping a dependency that will never receive a security patch.

For engineering: Treat rmzamora/timeline-bundle as prior art. It demonstrates the shape of a Sonata ↔ SpyTimelineBundle integration — service wiring, admin extension, and entity-to-timeline association — which is worth 30 minutes of reading when designing an activity-feed or audit-log feature. Do not add it to composer.json. If it is already present anywhere in our estate, open a ticket to remove it and replace the functionality with either a maintained feed library or a small owned event table. Note for the record: this is a Symfony bundle, not Laravel — any backlog item that assumed otherwise should be re-scoped.