Repository navigation
There is no Wolverine.Http.Fisher, where both siblings have one #3944
Description
There is a Wolverine.Http.Marten and a Wolverine.Http.Polecat, and no Fisher equivalent. Noting it here rather than in the wolverine repo because it belongs to the Fisher-parity story; the code itself would live beside its two siblings in wolverine/src/Http/, so move it if that reads better.
Not a blocker: a CritterWatch console flavour compiled against Fisher builds and runs against plain WolverineFx.Http, because nothing in its endpoints reaches for the store-specific half. But the store-specific package is where the aggregate/document HTTP attributes live, so any Fisher application that wants those has nothing to reference, and "the three flavours' csproj files are the same file with one word changed" stops being true at this line.
Low priority — recording it so the parity list is complete.
Activity
jeremydmiller commentedon Aug 15, 2026
Transferred from JasperFx/fisher#78, where it was filed against the Fisher parity list. It belongs here because the code does.
It is unblocked now.
Wolverine.Fisherexists insrc/Persistence/, and it already carries every base class the HTTP package derives from —WriteAggregateAttribute,ConsistentAggregateAttribute— so the port fromWolverine.Http.Polecatis close to verbatim: four files, ~100 lines.PackageIdwould beWolverineFx.Http.Fisher, matching its two siblings.Still low priority, as the original issue said: a Fisher-backed application builds and runs against plain
WolverineFx.Httptoday, because nothing in its endpoints reaches for the store-specific half. What the package buys is the aggregate/document HTTP attributes, and the parity claim that the three flavours' csproj files are the same file with one word changed.Add Wolverine.Http.Fisher, the missing third HTTP store integration (G…
Bump to 6.28.1 and write the changelog (#3952)