Marten 8.0 Plans

[jeremydmiller]

I know, I know, Marten 7 isn't that old yet and I'm working with plenty of teams who haven't made the leap to 7 yet because it was such a big change. This is to start a conversation about what Marten 8 would look like. First off though, the main goal is to enable a relatively easy path for Ermine (SQL Server backed subset of Marten) and possible event store implementations on top of CosmosDb and/or DynamoDb (with RavenDb actually being a possibility too randomly enough)

Make the migration from 7 to 8 as easy as possible!!!!

Scope

• I personally wanted to do this one: JasperFx Ecosystem Dependency Reorganization wolverine#954, but the advent of the Sable project from Bloomberg means to me that Oakton shouldn't die. I think that the plans for JasperFx.Framework still proceeds, but doesn't consume Oakton now so that we don't break Sable. We'll reach out to those folks though
• .NET 9.0? Not sure about the timing
• Move as much code as possible from Marten to Weasel -- even if that takes some generics gunk. More on this below:
• Fold Marten.CommandLine into Marten itself
• Rip out the projections into a new shared library of some sort. Also try to rip out as much of the async daemon code as possible into the same new library
• Re-organize tests, with part of the goal being to move a large set of "event capture & projection compliance" tests into a resuable library.
• Remove [Obsolete] APIs
• @elexisvenator 's bulk insert optimization changes

Internals to Weasel or JasperFx.Framework or new JasperFx.EventSourcing (?).

• Anything to do with code generation settings or application assembly determination goes to JasperFx.Framework
• IQueryHandler
• IStorageOperation
• IUpdateBatch
• IChangeSet
• IEvent & Event<T>
• Most of the projection support
• Async daemon subsystem

[Hawxy]

• Fix the discrepancy between the timestamp fields on IBatchEvents vs normal query events.