Skip to content

v6.0.0

Choose a tag to compare

@github-actions github-actions released this 22 Jul 16:46
· 29 commits to master since this release

6.0.0 (2026-07-22)

A focused, breaking release that inverts one dependency: IEntity/IEntity<TKey> now live in eQuantic.Core.DataModel, and eQuantic.Core.Data references it instead of the other way around. The engine can now build on the unified DataModel entity interfaces, and the package graph is finally acyclic and correctly ordered: eQuantic.Core.Data → eQuantic.Core.DataModel → eQuantic.Core.Domain.

What changed

  • IEntity / IEntity<TKey> moved to eQuantic.Core.DataModel (4.0.0), keeping the historical namespace eQuantic.Core.Data.Repository — so source stays compatible. eQuantic.Core.Data forwards the types (TypeForwardedTo), so assemblies compiled against ≤ 5.8 stay binary-compatible — they still resolve eQuantic.Core.Data.Repository.IEntity, now from DataModel.
  • IEntity<TKey> now extends IDomainEntity<TKey>: one entity satisfies both the domain and data-layer contracts (same GetKey/SetKey).

BREAKING CHANGE — upgrade together

eQuantic.Core.Data 6.0.0 requires eQuantic.Core.DataModel 4.0.0 and eQuantic.Core.Domain 4.0.0. Restoring 6.0.0 pulls them automatically. The only thing that breaks is mixing the new packages with an older eQuantic.Core.Data (≤ 5.8) in the same project — two assemblies would define IEntity, giving a duplicate/ambiguous type (CS0433/CS0311). Bump every eQuantic.Core.Data* and eQuantic.Core.DataModel/eQuantic.Core.Domain reference in lockstep and the type unifies through the forward. No code changes are required — the namespaces and members are unchanged.

Validated end to end against real servers (PostgreSQL, MySQL, MariaDB, SQL Server, Cassandra, MongoDB, Cosmos DB vNext), including a DataModel-based EntityHistoryDataBase entity exercising the full who/when audit through the inverted dependency.