Sentry Bundle Laravel Package

Product Decisions This Supports

• Error-monitoring build vs. buy: This package is a thin glue layer between Symfony2 and raven-php. It confirms that exception-to-Sentry wiring is commodity infrastructure — nothing to build in-house. The decision it supports is "buy/consume a maintained SDK," not "vendor a 21-star bridge."
• Roadmap sequencing for legacy Symfony estates: If any part of the portfolio runs Symfony 2.x, this package is a marker of technical debt. It supports a decision to schedule a framework/SDK upgrade rather than extend a deprecated integration.
• Framework-fit triage: It is not a Laravel package — it targets Symfony2's bundle/kernel model and raven-php (the pre-3.x Sentry client). For a Laravel roadmap this is a disqualifier, not a candidate. It supports the decision to standardize on sentry/sentry-laravel across PHP services.
• Telemetry coverage gap analysis: The package's only functional claim — auto-registering an uncaught-exception handler — is the baseline capability of every modern Sentry SDK. It supports a decision to audit which services have no error tracking rather than to evaluate this as a solution.
• Dependency-risk policy: Zero dependents and a deprecation notice ("replaced by Monolog") make it a useful negative example for a policy requiring maintained, non-deprecated dependencies with active upstream support in production paths.

When to Consider This Package

Adopt only under narrow, time-boxed conditions:

• You maintain a Symfony 2.x application on an EOL PHP version (5.x/early 7.x) that cannot be upgraded this quarter.
• You are already standardized on raven-php and need uncaught-exception forwarding as a stopgap before an SDK migration.
• You accept the deprecation and abandonment risk explicitly and have a dated removal plan — treat it as scaffolding, not architecture.

Look elsewhere in essentially every other case:

• Laravel (any version): use sentry/sentry-laravel for native exception handling, queue/job context, and request tracing.
• Symfony 3.4+ / 4+ / 5+: use sentry/sentry-symfony, which supersedes this bundle and uses the modern sentry/sentry SDK.
• Any stack with Monolog: a Sentry Monolog handler (upstream's own recommended replacement) gives structured logging capture without a framework-specific bundle.
• You need performance tracing, release health, or breadcrumbs: raven-php-era tooling cannot deliver these; the current SDKs can.
• You require active maintenance, security patching, or vendor support: this repository offers none of it — 21 stars, zero dependents, deprecated.

How to Pitch It (Stakeholders)

Bottom line: do not adopt; fund the migration instead.

For executives: this is a deprecated third-party bridge for an obsolete Symfony version. It has no dependents, no active maintenance, and has been formally superseded by the vendor's own recommended approach. Adopting it would create a new maintenance liability while delivering only basic crash reporting. The decision is not "should we use this package" but "when do we retire the legacy Symfony services that would need it."

For engineering: the capability we actually need — uncaught exceptions reaching Sentry with request context — is table stakes in the maintained SDKs. For Laravel, sentry/sentry-laravel; for Symfony 3.4+, sentry/sentry-symfony; for anything with Monolog, the Sentry Monolog handler. All three are supported, documented, and give us tracing and release context this bundle cannot. Effort is a one-time integration per service, measurable in days, not a program.

Ask: approve standardizing on the official Sentry SDKs across PHP services, and add "no deprecated dependencies in production paths" to our dependency policy. Treat any Symfony 2.x service still lacking error tracking as an input to the modernization backlog, not as a case for resurrecting this bundle.