9.1.1

Maintenance release

Updated Target Frameworks:

• netstandard2.0
• net4.6.2

Breaking Changes

• dropped net461

9.0.0

• Added support for .net6.0 #493.
• Change / Optimization: Commit and CommitAttempt do not create internal readonly collections anymore, it can be useless given the fact we can change properties of events.
• NEventStore.Serialization.Json: accepts a JsonSerializerSettings to configure the serializer.

8.0.0

• Added support for .net 5 #489.
• Added support for .net framework 4.6.1.
• Fixed InMemoryPersistenceEngine.AddSnapshot() behavior: adding multiple snapshots for the same tuple bucketId, streamId, streamRevision is not allowed; the updated snapshot will be ignored #484.
• Logging infrastructure switched to Microsoft.Extensions.Logging #454, #488.
• Reviewed Exception (and logging) messages: many of those that refer to a StreamId should also provide BucketId information #480

Breaking Changes

• Droppped support for .Net Framework 4.5, only .Net 4.6.1+ will be supported in 8.x. .Net Framewrok support will be dropped in a future revision.
• Logging switched to Microsoft.Extensions.Logging, old logging code and configuration functions have been removed.

V5 Release

Note: Version 5 is not backwards compatible with v4. Updating to v5 without doing some preparation work will result in problems

Breaking Changes

1. Underlying schema has changed for all v5 storage engines. In order to migrate a store from v4 to v5 use NEventStore.Migrations
2. The concept of a 'Bucket' has been added as a container for streams allowing multi-tenancy, partitions, multiple-bounded contexts, sagas, etc to be stored in the one store. The API changes have been such that, using extension methods, operations will work on the default bucket, unless a bucket Id has been explicitly supplied. This should mean minimal code changes for the user.
3. Stream Ids are now string based and are limited to 1000 characters.
   1. In the SQL engines the stream Id's are limited to 40 characters and are hashed versions of the actual StreamId.
   2. The hashing function can be overridden during wireup.

New Features

Polling Client

As an alternative to the dispatcher mechanism and improved replay / catch-up story we have implemented a CheckpointNumber in the stores that guarantees ordering across the streams. This number is guaranteed to increment but not guaranteed to be sequential. This allows you to get all Commits from a specific checkpoint and observe new ones. This implementation is polling based (and thus works for all engines) so it doesn't have the same low-latency attributes of the dispatcher mechanism. You can see how to use it here: https://gist.github.com/damianh/6370328 .In this, instead of the store tracking what has been dispatched, the onus is on the client to track what it has seen. And upon restart, start subscribing from what it last saw.

In the future I'd like to see / implement reactive clients that leverage stores that are observable.

Other Notes

1. Only SQL and MongoDB persistence engines are supported in this release. RavenDB engine will be shipped later.
2. RavenDB and MongoDB persistence engines are now in their own repositories and will have be shipped independently.