Doctrine Timestamp Laravel Package

Product Decisions This Supports

• PHP 8 roadmap support: The 2.0.0 release removes a major platform constraint by supporting PHP 8, which can unblock Laravel upgrade planning and reduce the need for custom compatibility shims.
• Breaking-change migration planning: The “class to trait” change is a major API change. It affects how the package is consumed, extended, or type-hinted, so product and engineering should treat 2.0.0 as a migration release rather than a drop-in upgrade.
• Build vs. buy / fork assessment: If the package’s class-based behavior was central to existing integrations, teams should decide whether to migrate to the trait model, delay adoption, or fork/pin the prior major version.
• Use-case fit: The package is more suitable for Laravel/PHP 8 applications that can adopt trait-based composition and do not rely on instantiating or extending the former class API.
• Documentation and support load: PM should anticipate migration-guide needs, upgrade communications, and potential support burden from consumers who upgrade without adjusting class-based usage.

When to Consider This Package

Consider adoption when:

• The application is already on, or actively moving to, PHP 8.
• The team is comfortable using a trait-based integration pattern rather than a class-based API.
• You can test the major-version migration in a staging environment and update internal docs, examples, and dependency pins.
• The package’s behavior fits an existing Laravel use case and reduces custom code or maintenance burden.

Look elsewhere or delay when:

• The application still requires PHP 7 or cannot absorb a major-version upgrade.
• Existing code depends on instantiating, extending, or type-hinting the former class API.
• The team needs a stable class-based contract and cannot refactor to trait usage.
• There is no clear migration path or ownership for validating the breaking change across services.

How to Pitch It (Stakeholders)

Executive summary: Version 2.0.0 modernizes the package for PHP 8 but introduces a breaking API change by replacing a class with a trait. This is a strategic compatibility upgrade, not a routine patch. It can support Laravel/PHP 8 modernization, but adoption requires a planned migration and regression testing.

For engineering: Treat 2.0.0 as a major migration. Search for direct class usage, inheritance, type hints, and instantiation patterns; update integrations to use the trait; verify PHP 8 compatibility across the dependency chain; and pin versions until the migration is validated.

For product/leadership: Approve adoption only with explicit migration effort and rollback options. The payoff is improved platform alignment and reduced legacy PHP risk; the cost is a breaking integration change that should be scheduled rather than assumed.