Laravel Revisionable Upgrade Laravel Package

Product Decisions This Supports

• Audit trail / version history as a feature, not a nicety. This package (an enhancement layer over venturecraft/laravel-revisionable) is the kind of dependency that shows up when you commit to "every edit to a record is traceable to a user and a timestamp." That single decision cascades into compliance posture (SOC 2, GDPR data-subject requests, HIPAA), customer trust narratives in enterprise sales, and support workflow ("who changed this price?").
• Build vs. buy vs. fork. The package's own existence is a signal: the community felt the base revisionable package was insufficient and extended it. The PM decision here isn't "adopt this" — it's "do we take a dependency, fork a dependency, or build a thin internal version-history trait?" The added methods are conveniences, not architecture.
• Scope of versioning. Revision packages force a product question: what gets versioned? Just business entities (invoices, contracts, pricing), or everything? Do we expose history to end users in the UI, or keep it internal for support and compliance? This package's helpers mostly shorten the developer path to that answer, not the user-facing one.
• Roadmap sequencing. If version history is on the roadmap for Q3, the dependency decision must land in Q1. Anything built on an unmaintained package needs a migration/exit plan budgeted before it's shipped, not after.
• Use cases: internal admin tools where every mutation is auditable; regulated verticals (fintech, health, HR); multi-tenant SaaS where "show me what changed" is a paid-tier feature; and support/CS workflows where reconstructing record state is currently done by hand.

When to Consider This Package

Consider it only if all of these hold:

• You are already on venturecraft/laravel-revisionable and are hitting its ergonomic limits — the helpers here are genuinely saving you custom code.
• Your team is comfortable owning a fork. Last release was September 2020; star count is in the low double digits. Assume upstream is dormant and that you are the maintainer from day one.
• The Laravel version in use is compatible with a package that predates most of Laravel 9/10/11 — verify before you plan around it.
• The versioning requirement is internal and non-contractual — i.e., if the package quietly breaks on a framework upgrade, you have time to fix it. Never put this behind a legal or regulatory promise without a maintenance owner and a test suite that proves the audit trail still holds.

Look elsewhere if any of these are true:

• You need a maintained, actively-developed dependency. Reach for spatie/laravel-activitylog or owen-it/laravel-auditing instead — larger communities, current releases, better Laravel-version tracking.
• You want state snapshots of models rather than event logs. Different tool, different shape.
• You are greenfield. Starting on an enhancement package for a base package that is itself aging is compounding risk for marginal convenience.
• Compliance is load-bearing. In that case, the honest answer is usually: use a maintained package, wrap it in your own interface, and write the tests yourself — don't inherit someone else's helpers as your audit backbone.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed PHP library that adds version-history helpers to Laravel applications. It supports the "who changed what, when" capability that enterprise buyers and auditors ask about. The tradeoff is clear: it saves engineering days now, but it has been unmaintained since 2020 and has a very small user base. My recommendation is treat it as a starting point for a fork we own, not as a vendor dependency — budget roughly a week of engineering to vendor it, pin it, and cover it with tests, and plan a mid-term exit to a maintained alternative. Do not let a customer contract rest on this package as-is.

For engineering: The helpers are useful and the code surface is small, but you are signing up to be the maintainer. Fork it into the repo, pin the Laravel constraint, add a test that asserts revisions are written on the models that matter, and open an issue to evaluate spatie/laravel-activitylog or owen-it/laravel-auditing as the eventual replacement. If the helpers aren't saving you real time in the first hour of evaluation, skip it — the base package plus a 40-line trait gets you most of the way with none of the fork debt.