Tentative Roadmap for Wolverine 3.0

By the way, JasperFx Software offers support contracts or tailored consulting engagements to help your shop maximize your success with Wolverine.

It’s an unfortunate fact of long running software tooling projects like Wolverine that decisions made years earlier won’t hold up perfectly as the usage requirements, underlying platform, and other tools it’s integrated with change over time. In the case of Wolverine, it’s time for a medium sized 3.0 release to make some potentially breaking API changes and changes to its original model to accommodate some use cases that weren’t part of the original vision.

This is all subject to change based on whatever feedback comes in, but right now I think the items that are absolutely in scope are:

1. De-coupling Wolverine from Lamar. That work has been unfortunately huge so far, but almost complete as I type this. At a minimum, Wolverine is going to be functional with both the build in ServiceProvider container and still Lamar itself. To a large degree, this was actually a prerequisite for the next bullet point
2. Make sure that Wolverine can be bootstrapped from basically any possible flavor of XyzHostBuilder and not just IHostBuilder like it is today. That’s a current annoyance, but also an absolute prerequisite for the next bullet point
3. Get Wolverine completely on the .NET Aspire train. Really just making sure that all the external infrastructure integrations with Wolverine that also have Aspire integrations like PostgreSQL, Sql Server, Rabbit MQ, Azure Service Bus, Kafka, and AWS SQS are able to correctly use the Aspire configuration. That’s really just a matter of using some IoC container integration and not a huge deal. I think that testing and documentation will be more work on that front than the actual development. I know that there are mixed opinions about whether or not Aspire is valuable, but this can’t be a reason why folks won’t consider using Wolverine in the future, so here we go.
4. Eliminate the goofy limitation that Wolverine has today where if a message type has multiple handlers, they can only run together in one logical transaction. A couple users and at least one JasperFx customer have wanted to run multiple local actions asynchronously on the same message. Wolverine 3.0 will enable this. This is the result of historical reasons dating back to FubuTransportation from the early 2010’s that no longer make the slightest sense now
5. Maybe allow Wolverine to address multiple service brokers of the same type in a single application. I.e. 2 or more connections to Azure Service Bus or Rabbit MQ etc. I think that might take breaking API changes, so it’s time to look at that now

Beyond that, I think there are some additive features I just didn’t want to work on right now until the 3.0 work is complete:

• An HTTP messaging transport — which I think we really want inside of Wolverine as a precursor to the long planned “Critter Stack Pro” add on tooling. Which also might help enable:
• Some improvements for dynamic multi-tenancy where you want to spin up or down tenants in a running application without downtime
• Improving the EF Core integration with Wolverine to bring it a bit up to parity with the existing Marten integrations. That would potentially include multi-tenancy support and more middleware and productivity shortcuts for Wolverine
• I’d like to completely reconsider our bootstrapping, especially in an application that combines both Marten & Wolverine. I think there’s some room for a customized CritterStackApplicationBuilder or CritterStackWebApplication model. More on this later.

I don’t really want this to be a huge release that takes very long, and I absolutely don’t want this to require very many changes at all for our users to adopt this.