Mssql Bundle Legacy Laravel Package

Product Decisions This Supports

• Build vs. buy for supporting infrastructure. This package sits in the "glue" layer of the stack — the kind of thing a team could reimplement in a day or two but would rather not own. The 2.2.0 release doesn't add user-facing capability; it changes the package's dependency posture. That is a maintenance-ownership signal, not a feature signal, and should be weighed as such when deciding whether to keep absorbing someone else's dependency graph.
• Dependency and upgrade policy for the platform. 2.2.0 adds a runtime requirement of doctrine/common:*. The wildcard is the decision-relevant detail: it asks Composer to accept any published version of doctrine/common, including future majors with breaking changes. This is a legitimate reason to freeze, pin, or gate adoption rather than auto-merge the bump.
• Roadmap sequencing for Laravel version upgrades. Because the requirement is unbounded, the resolved doctrine/common version is now a function of whatever else is in the lockfile and when the lockfile is regenerated. That makes this package a potential non-deterministic contributor to future Laravel/PHP upgrade work — worth booking as risk on the upgrade epic rather than discovering it mid-sprint.
• Risk acceptance and security review thresholds. An unbounded transitive dependency widens the surface that a supply-chain review must cover and complicates SBOM accuracy. If your org already requires pinned/bounded constraints for runtime dependencies, 2.2.0 is a policy exception request, not a routine bump.
• Use-case validation before investment. If the only reason this package is in the tree is inflection or class-utility helpers, illuminate/support and symfony/string already cover most of it, and the whole doctrine/common question disappears. That's a cheaper answer than negotiating constraint policy with a maintainer.

When to Consider This Package

Adopt (or keep) it when:

• You already run doctrine/common elsewhere in the dependency graph, so the new requirement is largely satisfied by something you're carrying anyway. Confirm with composer why doctrine/common before assuming this.
• You have lockfile discipline — committed composer.lock, reviewed dependency diffs, and no wildcard-tolerant CI that silently re-resolves on every build. Under those conditions the wildcard is contained.
• The package's value is convenience and Laravel-native ergonomics, not correctness-critical business logic, and you're comfortable owning a small fork or drop-in replacement if maintenance stalls.
• You need the 2.2.0 behavior specifically — i.e., something in your stack requires doctrine/common to be present and previously the package's constraints conflicted. That's the case this release appears to unblock.

Look elsewhere (or vendor a minimal implementation) when:

• doctrine/common is not otherwise in your stack. You'd be adding a transitive dependency to satisfy a package that may not need it — a poor trade for glue code.
• Your policy requires bounded version constraints for runtime dependencies. * fails that bar, and you shouldn't relax the policy for a convenience package.
• You're on a PHP/Laravel version matrix where the unbounded resolution can drift between environments (e.g., app servers vs. queue workers vs. CI images resolving at different times).
• The package is load-bearing for user-facing behavior. The 2.2.0 change suggests dependency management here is informal; don't build product surface on top of that without a pin.
• A maintained first-party or framework-provided equivalent covers your use case.

Immediate actions if you do adopt: pin the package to an exact or bounded constraint, add doctrine/common explicitly to your root composer.json so you control the version rather than inheriting it, and file an upstream request to bound the constraint (e.g., ^3.0 || ^4.0) — an unconstrained * in a runtime dependency is usually an oversight, not a design decision.

How to Pitch It (Stakeholders)

Executive summary. Version 2.2.0 is a minor release with no new product capability. Its only substantive change is a new runtime dependency on doctrine/common, declared with an unbounded (*) version constraint. The package remains usable, but it now contributes a small amount of non-determinism to our dependency resolution and a modest expansion of our supply-chain surface. This is not a blocker; it is a reason to pin the dependency and keep the package out of critical-path product logic.

For engineering. Treat 2.2.0 as a dependency change, not a feature upgrade:

• Add doctrine/common to the root composer.json with a bounded constraint so resolution is under our control, and pin the package itself.
• Review the composer.lock diff explicitly; do not let CI re-resolve without a lockfile.
• Run composer why doctrine/common to confirm whether we're already carrying it. If we aren't, question whether this package earns a new transitive dependency at all.
• Verify the resolved version against our PHP and Laravel support matrix before merging, and re-verify on any future lockfile regeneration.
• If the package is only providing string/inflection/utility helpers, evaluate illuminate/support or symfony/string as a drop-in and retire the dependency question entirely.

Bottom line. Low feature value, low-to-moderate dependency risk, cheap to mitigate. Approve with a pin; don't approve on autopilot.