Pardon the mess, but the Critter Stack 2026 releases are heavily underway in the JasperFx GitHub Organization. Busy enough that I am getting hit with GitHub rate limiting messages the past couple days and I think that’s a good sign about our productivity? It’s also blessedly coincided with a couple very quiet days in the community which has certainly helped too!
The main goals are to:
- Get CritterWatch out the damn door!
- Optimize the “cold start” times across the entire stack, have a better story for “Serverless” usage and, knock on wood, get to AOT compliance. To be clear, this will change the pattern of our previous Roslyn runtime compilation into a development time only thing where pre-generation of Wolverine or Marten types will be mandatory for production usage. And that’s the part I expect to be a little bit controversial or inconvenient.
- Bring Polecat up to par quality wise with Marten. Polecat has had growing pains.
- Adjusting some of our default settings to reflect more optimized usage for greenfield usage, which I mostly outlined in this post. But don’t worry, all of this will be documented in the migration guide, Marten will have a
RestoreV8Defaults()and Wolverine is getting aRestoreV5Defaults()to make it easier to stay right were you are. Some of this is getting driven by real efficiency concerns, and other parts are purposely meant to enable CritterWatch management and oversight of production applications.
This wave of releases is going to include:
- JasperFx and JasperFx.Events 2.0
- Weasel 9.0
- Marten 9.0
- Polecat 4.0 (Event Sourcing & Document Db w/ SQL Server)
- Wolverine 6.0
- CritterWatch 1.0 – Our white whale, our “Duke Nukem Forever” release, “Winds of Winter” finally coming out so we can find out if Jon Snow survives! Add in Half Life 3 too. No seriously, it’s coming out on May 18th come hell or the river don’t rise.
For some other details:
- There’s plenty of low level performance optimization and object allocation savings happening, but I don’t yet have numbers to know how much difference that’s going to make yet. We will be doing much more benchmarking before the release though
- We’re pulling Newtonsoft references out of the main tools altogether, but replacing the integration with extra extension packages. That feels like the end of an era!
- We’ll do the inevitable work of eliminating
[Obsolete]APIs, but I don’t think there’s much - We’re doing a huge amount of work to promote code sharing between Marten and Polecat, with me hoping that that improves Polecat especially. Some of that is driven by CritterWatch needs. This is also happily reducing code duplication throughout the Wolverine codebase as well.
- .NET 8 support was dropped, but we’re maintaining .NET 9 and .NET 10 for the lifetime of these versions. I realize that .NET 9 is EOL later this year, but I’m not eager to get yelled at for dropping it earlier than some of our users. We’ll add .NET 11 whenever that hits. For anyone wondering why this is a big deal at all, our usage of EF Core means that we do struggle somewhat with diamond dependency conflicts through major .NET versions.
- Marten is getting a more efficient option for “Dynamic Consistency Boundaries” (DCB) using PostgreSQL HSTORE
- There was also a big time round of code de-duplication in Weasel across the database engines that we support
Migration?
Other than some changes to the shape of our MultiStreamProjection types in Marten and Polecat, I’m expecting no other breaking changes except for some public types moving namespaces. I’m confident this time around that we’ll have a comprehensive migration guide that will cover all of those moves in a form that should be helpful for both humans or LLM tools.
If you utilize the new defaults though, there will be database migrations for extra fields and new tables that have been added in the past year or two for enhanced auditing and observability — but all of this will be purely additive.
The Shade Tree Developer 