File Bundle Laravel Package

Product Decisions This Supports

• Platform upgrade roadmap (Symfony 6.4 → 8.x). The headline of v1.1.0 is Symfony 8.0/8.1 support across config, DI, http-foundation, http-kernel, mime, and string. This removes a blocking dependency from our framework upgrade plan and means we do not need to fork, patch, or budget migration effort for this component. Treat it as a roadmap de-risker, not a feature.
• Build vs. buy for file handling. The release hardens the part of the bundle we would otherwise have to write and own: failed unlink and write operations are now logged with clearer checks. That is exactly the observability/audit surface a PM would otherwise spec into a custom implementation, so this release strengthens the buy case.
• Security posture and vendor viability. The Twig advisory (CVE-2026-46639 and related) is fixed on a dev dependency only — build/test time, not runtime — so there is no production exposure to triage. The useful signal is cadence: the maintainer shipped a CVE response and a CI refresh in the same release, which is what we want to see from a component we depend on for file I/O.
• Scope discipline for the roadmap. Nothing user-facing changed. Do not book this against a customer-facing epic; it belongs in maintenance/upgrade work with a small, well-bounded cost.
• Adoption gating for the portfolio. The compatibility floor moved to PHP 8.4+ with Doctrine ORM 2.19+/3.0+. Any service still on PHP 8.2/8.3 is now out of range for this version, which is a portfolio decision, not just an engineering one.
• Concrete use cases this supports: document and asset uploads, media libraries, admin file managers, and scheduled cleanup/temp-file jobs where a silent failed unlink is the failure mode that bites us.

When to Consider This Package

Consider it when:

• You run Symfony services on 6.4 or 7.x and have Symfony 8 on the roadmap — this release is the enabler.
• You need straightforward file CRUD plus logged failure handling, and you already run Doctrine ORM.
• Your team has no appetite to own and maintain a file-abstraction layer.
• You want a small dependency with visible maintenance activity rather than a bespoke internal module.

Look elsewhere when:

• Your stack is Laravel. This is a Symfony bundle; the integration cost against Laravel's filesystem and container abstractions outweighs the benefit. For Laravel services, use the framework's own filesystem/storage primitives.
• You are below PHP 8.4. The floor is hard, not advisory.
• You need capabilities beyond basic file operations — S3/CDN delivery, streaming, virus scanning, image transformation. Verify coverage explicitly; do not assume it from these notes.
• The need is trivial (one upload form) — framework primitives are cheaper than a dependency.
• You require an SLA or commercial support. Nothing here speaks to support terms; single-maintainer risk is unassessed.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release with no user-facing change. It does two things that matter to us: it keeps the component compatible with the framework generation we plan to move to, and it keeps its security dependencies current. Cost is low — a version bump plus a test pass — and the payoff is that a known upgrade blocker disappears from the roadmap.

For engineering: Bump to v1.1.0 on services already on PHP 8.4 and Doctrine 2.19+/3.0+. Run the suite and specifically verify the new file-operation error logging surfaces where we expect it in our logging pipeline — that is the behavioural change in this release. The Twig advisory is a dev dependency, so it affects builds and CI, not production; refresh lockfiles accordingly. Services below PHP 8.4 stay pinned until they upgrade.

Recommendation: Adopt in Symfony services that meet the PHP 8.4+ and Doctrine floors; defer for Laravel services; revisit the support/SLA question before this becomes load-bearing for a revenue-critical path.