Announcing Ory’s new versioning scheme

We’re introducing a new versioning system for all Ory products, open source and enterprise. This change makes releases easier to follow, improves predictability, and ensures that every Ory deployment has a clear and seamless upgrade path.

Why we changed versioning

Ory ships fast. Our continuous delivery model means new features, fixes, and performance improvements land frequently. But until now, version numbers didn’t clearly distinguish between open source releases and enterprise-only builds. This created friction for operators, contributors, and customers.

Our new versioning scheme:

• Standardizes version numbers across all Ory products.

• Distinguishes open source releases from enterprise builds.

• Preserves backwards compatibility across patch and minor versions.

• Makes upgrade paths transparent and predictable.

• Surfaces version information directly in Ory Console and APIs.

The new format

We use calendar versioning:

YY.Q.B[-TAG]

• YY: Year (two digits, e.g., 25 for 2025)

• Q: Quarter (1–4)

• B: Build number, incremented with every enterprise release

• TAG: Optional pre-release marker (alpha, beta, rc)

Examples

Version Description Channel 25.2.0 Open source release (Q2 2025) OSS + Enterprise 25.2.1 Enterprise patch Enterprise 25.3.0-rc.1 Release candidate for 25.3.0 Enterprise

Open source releases are always published as .0 builds (e.g., 25.2.0). Enterprise customers receive continuous patch releases (e.g., 25.2.1, 25.2.2).

Release policy at a glance

• Enterprise (OEL): Every internal release gets a version (YY.Q.B). Always backwards compatible. Distributed through private registries.

• Open source (OSS): Only .0 versions are promoted. Distributed via GitHub and Docker Hub. Always signed, multi-platform binaries.

• Pre-releases: alpha, beta, and rc builds for testing and staged rollout.