Wolverine 3.0 Plans

[jeremydmiller]

Long story short, I think this suddenly became a much higher priority issue for me due to some problems at a JasperFx client. The migration from 2.0 to 3.0 should be as easy as possible

The major arching proposed changes:

• Removing the Lamar dependency. The question now is "does Wolverine only work with the built in DI container, or continue to work with Lamar as well? This might include building out some shims for Lamar/STructureMap style service registrations in JasperFx.Core as a polyfill
• A new IServiceCollection.AddWolverine() bootstrapping mechanism. It's absolutely vital that Wolverine can be used with bootstrappers other than IHostBuilder as this is holding Wolverine back quite a bit
• Support .NET Aspire for all transports and database storage types. I know a lot of vocal or active Wolverine users do not care, but it's David Fowler's world and we all just live in it. Besides, a JasperFx client wants to use it.
• Making a handful of API adjustments, especially a consideration of the Endpoint API that's grown
• Eliminate the automatic scanning for extension assemblies -- not sure if anyone actually uses this anyway. Very old leftover from FubuMVC that was wolverine's ancestor project

[haefele]

I can imagine that it's a big amount of work, but ever considered leaning more onto the IOptions stuff for WolverineOptions?
The IWolverineExtension interface seems extremely similar to IConfigureOptions from IOptions.
(Similar thing in Marten with IConfigureMarten)

Also for example the app.MapWolverineEndpoints(config => { /* Do something with the config */ }); feels a bit out of place.
More "in line with .NET stuff" would be a pair of services.AddWolverineEndpoints(config => ...) and app.MapWolverineEndpoints() methods.

[jeremydmiller]

I'd call the first a very low priority. A lot of Wolverine is descended from an older (failed) framework and was put in place long before stuff like IOptions got into .NET.

As for the 2nd, I don't have a huge opinion, but an Add syntax instead of Map is fine. I did that mostly to be consistent with Minimal API. I don't want both the services.AddWolverineEndpoints() and app.MapWolverineEndpoints() though. I loathe that clumsiness with .NET web application setup. Guess we'll have to when Lamar goes away though. Bleck.

[haefele]

Just got another idea: Maybe with 3.0 we can also change DocumentAttribute.Required to be true by default - I think that's more intuitive.