Recurrent Fixtures Test Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy / dependency approval for database-touching features. The package sits on top of doctrine/dbal, which is the standard bridge for schema introspection, column-type mapping, and cross-driver SQL handling in Laravel. That positions it as infrastructure for features like schema diffing, migration tooling, admin/CRUD generators, or audit/versioning of table structures — decisions where reliability matters more than surface area.
• Framework upgrade planning (highest-value signal from v0.1.12). Widening the doctrine/dbal constraint to accept both v2.x and v3.x is a compatibility release. dbal v3 was the breaking jump that arrived with Laravel 9-era stacks. Supporting both ranges means one dependency can serve projects on older and current Laravel lines, which directly affects whether we can adopt it across a mixed-version portfolio or must fork/pin per app.
• Roadmap scoping for upgrades. If a near-term roadmap item is "move remaining services to Laravel 9+," this release removes a known blocker class. That is a scheduling input, not a feature input.
• Risk posture for a pre-1.0 dependency. v0.x signals the public API is still unstable and breaking changes are permitted on minor bumps. This supports a decision to pin exact versions and isolate the integration behind our own adapter rather than calling it from many call sites.
• Use cases it does not justify. Nothing in this release adds product-facing capability. It should not be used to justify new feature work, and it should not shift a "defer" decision to "build now."

When to Consider This Package

Consider it when:

• We have concrete work that requires schema introspection or SQL that must behave consistently across MySQL/Postgres/SQLite, and we would otherwise hand-roll driver-specific logic.
• Our fleet is version-diverse (some apps pre-Laravel 9, some current). Dual dbal v2/v3 support is the specific reason to evaluate now rather than later.
• We are comfortable pinning a 0.x dependency and wrapping it behind an internal interface so a future breaking release is a one-file change.
• The dbal constraint is the only compatibility question outstanding; the rest of the package's Laravel support matrix still needs to be checked explicitly.

Look elsewhere when:

• We need a stable, semver-protected API contract — a 0.x package cannot offer that, and every minor release is a potential break.
• Our stack is single-version and modern, in which case dual dbal support buys nothing and a narrower, better-maintained alternative may be safer.
• The dependency graph is a concern: doctrine/dbal is a substantial transitive addition, and if we only need a thin slice of it, that is weight we may not want in a latency- or footprint-sensitive service.
• Maintenance signals (release cadence, issue responsiveness, test coverage, single-maintainer risk) are unknown. This release is a maintenance signal, but one commit is not a trend — I would want to see the last 6–12 months of activity before committing.

How to Pitch It (Stakeholders)

One line: A small, pre-1.0 Laravel/PHP package built on doctrine/dbal; its latest release is a compatibility widening, not a feature.

For executives: This release is housekeeping with real operational value. It lets the same dependency run against both the older and newer major versions of a core database library, which reduces friction when we upgrade Laravel versions and lowers the chance we get stuck maintaining a fork. It does not add product capability, and it does not change our cost or timeline on its own. The caveat is maturity: at version 0.1.x the API is explicitly unstable, so any adoption should be scoped and pinned.

For engineering: v0.1.12 relaxes the doctrine/dbal constraint from a single major line to ^2.0|^3.0. Practically, that means we can deploy the package to apps on both Laravel 8- and 9-era stacks without a Composer conflict, and we get a supported path off dbal v2 whenever we are ready. Recommendations before we commit: pin the exact version, wrap the package behind a thin internal adapter so a 0.x breaking change costs us one file, and confirm the full Laravel/PHP support matrix plus the transitive weight of dbal in our dependency audit.

Decision requested: Approve a time-boxed evaluation in one non-critical service, not a portfolio-wide adoption. Success criteria are (a) no Composer conflicts across our version range and (b) the adapter boundary holding with no leakage into domain code.