
Time for an update on Critter Stack release plans, and a follow up on my previous Critter Stack Work in Progress post from March. The current plan is to release Marten 8.0, Weasel 8.0, and Wolverine 4.0 on June 1st. It’s not going to be a huge release in terms of new functionality, but there are some important structural changes that will help us build some future features, and we needed to jettison older .NET versions while getting onto the latest Npgsql. “CritterWatch” is still very much planned and a little bit in progress, but we’ve got to get these big releases out first.
The key takeaways are that I want to essentially freeze Marten 7.* for everything but bug fixes right now, and probably freeze Wolverine 3.* for new feature development after a last wave of pull requests gets pulled in over the next couple days.
I’m admittedly too drowsy and lazy to write much tonight, so here’s just a dump of what I wrote up for the rest of our core team to review. I think we’re already at the point where we’re ready to just work on documentation and a few last touches, so the mass majority of this doesn’t get done in time, but here’s the full brain storm:
First though, what’s been done:
- .NET 6 & 7 were dropped
- Updated to Npgsql 9 across the board
- Dropped all synchronous APIs in Marten
- Deleted some [Obsolete] APIs in Marten
- Consolidation of supporting libraries to a single JasperFx library
- JasperFx has that new consolidated configuration option for common configuration like application assembly, code generation, and the stateful resource AutoCreate mode
- Pulled out event projections and core event store abstractions to a new JasperFx.Events library
- Removed code generation from all projections
- Better explicit code options for aggregations and event projections
- Wolverine 4 has better handles envelope storage & the transactional inbox/outbox for modular monoliths
- Improved “Descriptor” model to describe the static configuration of Wolverine and/or Marten applications that we’ll use for CritterWatch too
- Expanded commands for dead letter queue management in Wolverine that was meant for CritterWatch
- Multi-tenancy options in Wolverine for SQL Server or PostgreSQL w/o Marten, multi-tenancy usage with EF Core
Punchlist?
- Marten 7.40.4 release w/ a pair of outstanding PRs
- Cherry pick commits to Marten “master”
- JasperFx & JasperFx.Events 1.0
- Documentation website?
- Weasel “master” branch
- All tests should be passing
- Marten “master” branch
- All tests should be passing
- Documentation website should be building – that’s going to take some effort because of code samples
- Get Anne’s PR for tutorials in (cool new guided tour of building a system using Event Sourcing and Event Driven Architecture with first Marten, then Wolverine)
- Stream Compacting feature – for a JasperFx customer (this is definitely in for Marten 8, this is a big improvement for keeping a larger system running fast over time by compacting the database)
- Fix the optimized projection rebuild options? Or rip it out and leave it for CritterWatch?
- Ability to overwrite the event timestamp (relatively easy)
- Migration guide
- Figure out what the proper behavior of “Live” aggregations when there’s some ShouldDelete() action going on
- Wolverine
- One last 3.14 release with easy to grab pull requests and bug fixes
- Rebase on 3.14
- Fork off the 3.0 branch
- 4.0 becomes main branch
- All tests should be passing
- Documentation website should build
- Migration guide
- Critter Watch preparation
- When integrated w/ CritterWatch, Wolverine can build the descriptor model for the entire application, including EventStoreUsage. No idea where this work stands right now. Did quite a bit earlier this year, then went off in a different direction
- Review all Open Telemetry usage and activity naming across Marten and especially Wolverine. Add Open Telemetry & Metrics metadata to the descriptor model sent to CritterWatch. I think this is somewhat likely to get done before Wolverine 4.0.
- Ability to send messages from CritterWatch to Wolverine. Might push through some kind of message routing and/or message handler extensibility
Nice to do?
- Consider consolidating the stateful resource / AutoCreate configuration so there are fewer thing to configure. See Managing Auto Creation of Database or Message Broker Resources in the Critter Stack vNext
- Programmatic message routing in Wolverine that varies based on the message contents? This is around options to route a message to one of a set of destinations based on the message core. Thinking about concurrency here. Could be done later.
- More open issues in the Marten 8 milestone, but it’s about time to drop any issue that isn’t a breaking change
- More open issues in the Wolverine 4 milestone or Wolverine in general
- Ermine/Polecat readiness? (Marten ported to SQL Server)
- Spike it out?
- Look for opportunities to pull shared items into Weasel?