Product Decisions This Supports
- API caching strategy (performance roadmap) — unchanged in substance. The bundle still answers the same narrow question: "how do we get HTTP caching (Cache-Control, ETag, Last-Modified, conditional 304s) onto our REST endpoints without hand-writing it in every controller?" The value lever (cheap bandwidth/origin offload on read-heavy endpoints, better polling behavior for mobile clients) is the same.
- Vendor vs. depend — still the real decision, and now better evidenced. With v4.0.0 landing as a single "make this bundle compatible with sf6" release after a multi-year gap, the "copy the few classes into our own namespace" path remains the low-regret option: a major-version bump with a one-line changelog is cheaper to absorb by ownership than by dependency management.
- Symfony 5 → 6 upgrade sequencing. If this package was ever on a "sf6 upgrade blockers" list, v4.0.0 removes it. That's a genuine roadmap input: the cost of a Symfony upgrade no longer includes rewriting cache-header plumbing on FOSRestBundle controllers.
- Legacy platform support / staying on FOSRestBundle. Adopting or upgrading to v4 still signals "we are staying on the FOSRestBundle stack for this release train." The new release extends the viable life of that stack through Symfony 6 — which makes it more tempting and therefore more important that the "modernize the API layer or defer again" call is explicit and recorded, not drift.
- Maintenance risk register (new input). The project's posture has moved from frozen to sporadic: one release since July 2022, minimal-detail note, still roughly one star and zero dependents. Sporadic single-purpose releases are not a support commitment for a component on the request path — but they do mean an already-shipped v3 install isn't stranded when the platform moves.
- Build vs. buy vs. copy. Still roughly a wash on cost between "buy" and "copy the MIT source." Capability gap to the framework has not changed: Symfony's native
#[Cache] attribute / AbstractController::setCache() remains the baseline to beat.
When to Consider This Package
Consider it when all of the following hold:
- You already run FOSRestBundle with its controller/annotation conventions; the value is entirely incremental on top of that.
- You are moving an existing FOSRestBundle app onto Symfony 6 and want per-action cache headers rolled out without refactoring controllers — this is now the strongest remaining justification, and it did not exist before v4.0.0.
- You have read the v4.0.0 diff and tag and confirmed the change is limited to composer constraints plus any necessary signature updates. A major bump documented as one line ("Make this bundle compatible with sf6") is not enough signal on its own for a production request-path component — verify PHP/Symfony constraint ranges, CI status, and whether behavior changed.
- Your need is narrow and understood: response cache headers plus conditional-request handling. Nothing more.
- You accept the maintenance posture: ~1 star, 0 dependents, first release since July 2022, repo transferred M6Web → BedrockStreaming. You are the maintainer in practice.
Look elsewhere — or don't adopt — when:
- You're starting a new service, or you're on Symfony 6.1+ and can use the native
#[Cache]/setCache() path. Note that v4.0.0 strengthens this objection: by targeting Symfony 6, the package now competes directly, version-for-version, with a capability the framework ships for free. The old "we're pinned to an older Symfony" rationale is gone.
- You need security patching SLAs, vendor support, or an escalation path. A sporadic release cadence does not change this.
- You need caching semantics beyond response headers: invalidation, tag-based purging, ESI, or reverse-proxy (Varnish/Fastly/Cloudflare) integration. This bundle still does not solve invalidation, which is the harder half of the problem.
- You require a demonstrated maintenance cadence (regular releases, responsive issues, tests on modern PHP). One compatibility commit after three years is a data point, not a cadence — don't extrapolate a support commitment from it.
Recommendation (unchanged): treat it as a reference implementation, not a dependency. Vendor the few classes into App\Api\Cache under MIT, absorb the Symfony 6 constraint fixes yourself, and delete the supply-chain risk. If you already run v3 successfully and are moving to Symfony 6, taking 4.0.0 is reasonable — take it and vendor it in the same PR. Either way, budget the verification step: someone must actually read the release diff rather than trust the one-line note.
How to Pitch It (Stakeholders)
For executives (one paragraph): The small open-source add-on we evaluated for API caching shipped its first update in roughly three years — a compatibility release for the current framework version. That's mildly good news: it means the project isn't dead, and teams already using it aren't stranded by a platform upgrade. It does not change our recommendation. The package is still effectively unowned (one star, zero downstream dependents, no support path), the update is a major version described in a single line, and the capability it provides is now built into the framework version it just became compatible with — so the case for taking it as a dependency is weaker than before, not stronger. We'll implement the same cache headers using the framework's native support, or vendor the ~100 lines we need under our own ownership. Cost: roughly a day of engineering, versus an indefinite unowned dependency on the critical request path.
For engineering leads: v4.0.0 is a Symfony 6 compatibility bump — a major version, one-line changelog, first release since July 2022. Two consequences. First, it clears the "can't use it on sf6" objection, so if you're on an existing FOSRestBundle app and want per-action cache headers without touching controllers, this is now viable. Second, it erases the last good reason to depend on it: it now targets exactly the Symfony versions where native #[Cache]/setCache() does the same job with framework maintenance behind it. Treat it as a reference implementation. If you take it, read the actual tag diff first (constraint ranges, signature changes, CI green), vendor the classes under our own namespace, and own them. Still no invalidation, no purging, no proxy integration — don't let "it supports sf6 now" get read as "it's supported."