Versioning and support

This page lists the release lines of Ocoda Event Sourcing, how to install each one, and which versions of NestJS, Node.js and the databases they are tested with. The support policy itself lives in SECURITY.md and SUPPORT.md on GitHub.

Release lines

Line	npm dist-tag	Branch	Status	Fixes
4.x	latest	master	Supported	Bug fixes, security fixes and new features, released as 4.x minor and patch versions.
3.x	latest-3	3.x	Supported until at least 2027-03-31	Security and critical bug fixes, released as 3.x patch versions.
2.x and older	none	none	Not supported	None. Upgrade to 3.x or 4.x.

To move an application from 3.x to 4.0, follow Migrating from 3.x to 4.0. The documentation of 3.x is at ocoda.github.io/event-sourcing/v3.

3.x support

3.x receives security and critical bug fixes until at least 2027-03-31, released as 3.x patch versions from the 3.x branch. That includes the DynamoDB store, which 4.x doesn’t have. New features go into 4.x only. The end of 3.x support will be announced here and in SECURITY.md before it happens.

npm dist-tags

• latest points to 4.x: npm install @ocoda/event-sourcing installs it.
• latest-3 points to the newest 3.x release. Install it with npm install @ocoda/event-sourcing@latest-3.
• next carried the 4.0 prereleases (4.0.0-next.N), which 4.0.0 supersedes: move to 4.0.0.

To stay on a line regardless of the tags, install it by major version, for example npm install @ocoda/event-sourcing@4 or npm install @ocoda/event-sourcing@3.

Packages

The core and its integrations are released together and always share the same version number. Install the integrations in the same version as the core.

Package	4.x	3.x
@ocoda/event-sourcing	Yes	Yes
@ocoda/event-sourcing-postgres	Yes	Yes
@ocoda/event-sourcing-mariadb	Yes	Yes
@ocoda/event-sourcing-mongodb	Yes	Yes
@ocoda/event-sourcing-dynamodb	No, see DynamoDB	Yes

Tested versions

CI runs the tests of the core on Node.js 22 and 24, and the tests of each store against every database version listed below for its line.

	4.x	3.x
NestJS	12	11
Node.js	22.12 or later (tested on 22 and 24)	20 or later (tested on 22 and 24)
Module format	ES modules only; CommonJS applications load them through require()	CommonJS
PostgreSQL	14, 15, 16, 17, 18	13, 14, 15, 16, 17
MariaDB	10.11, 11.4, 11.8, 12.3 (long-term releases), 13.0 (rolling release)	10.11, 11.4
MySQL, with the MariaDB store (from 4.1)	8.4, 9.7 (long-term releases), 26.7 (Innovation release)	Not tested
MongoDB	7, 8 (the newest 8.x, 8.3), 9.0; 8.3 and 9.0 with mongodb 7.3 or later	6, 7, 8.2
DynamoDB	Not available	DynamoDB Local 3.3.1
Database drivers	Peer dependencies, installed by you	Installed by the integration

Managed services, and other servers that are compatible with one of these databases, aren’t in this table: see Other databases.

TypeScript projects on 4.x need TypeScript 5.4 or later: the type declarations of the command and query buses use NoInfer.

MariaDB supports a rolling release only until the next one, and MySQL an Innovation release, so the 4.x tests move on to each new rolling and Innovation release. MySQL 8.0 reached its end of life in April 2026 and isn’t tested; see Supported versions on the MariaDB and MySQL page. PostgreSQL 13 and MongoDB 6 reached their end of life at their vendors in 2025, so 4.x is no longer tested on them; 3.x still is. See Database server versions.

On 4.x the drivers are peer dependencies with these ranges: pg ^8.15.0 with pg-cursor ^2.14.0, mongodb ^6.10.0 || ^7.0.0, and mariadb ^3.5.3. See Database drivers are peer dependencies.

Each driver release supports the database servers up to a version of its own, so a new server can need a newer driver than the lowest one the range allows. MongoDB 8.3 and 9.0 need mongodb 7.3 or later: 6.21, the last 6.x release, and 7.0 to 7.2 support MongoDB up to 8.2 (see MongoDB). 3.x installs the 6.x driver itself, so it supports MongoDB up to 8.2, the newest version its tests run on.

Semantic versioning

The packages follow semantic versioning:

• a major version for a breaking change, with a migration note in the changelog
• a minor version for a new feature
• a patch version for a bug fix

Every change to a published package comes with a changeset, which becomes its entry in the changelog. The changelog of each package is in its folder on GitHub, for example the core’s CHANGELOG.md.

• 4.x: minor and patch releases from master, under the latest tag. The 3.x APIs that 4.0 deprecates, such as the positional appendEvents and commit(), keep working until 5.0.
• 3.x: only patch releases, from the 3.x branch, under the latest-3 tag.

Getting help and reporting problems

• For questions, bugs and feature requests, see SUPPORT.md.
• Report a vulnerability privately, never in a public issue. SECURITY.md explains how.

One volunteer maintains this project, so support is best-effort.