Skip to main content

Versioning

Oasis Core​

Oasis Core (as a whole) uses a CalVer (calendar versioning) scheme with the following format:

YY.MINOR[.MICRO][-MODIFIER]

where:

  • YY represents short year (e.g. 19, 20, 21, ...),

  • MINOR represents the minor version starting with zero (e.g. 0, 1, 2, 3, ...),

  • MICRO represents (optional) final number in the version (sometimes referred to as the "patch" segment) (e.g. 0, 1, 2, 3, ...).

    If the MICRO version is 0, it will be omitted.

  • MODIFIER represents (optional) build metadata, e.g. git8c01382.

The YY version must be bumped after each new calendar year.

When a regularly scheduled release is made, the MINOR version should be bumped.

If there is a major fix that we want to back-port from an upcoming next release and release it, then the MICRO version should be bumped.

The MODIFIER should be used to denote a build from an untagged (and potentially unclean) git source. It should be of the form:

gitCOMMIT_SHA[+dirty]

where:

  • COMMIT_SHA represents the current commit’s abbreviated SHA.

The +dirty part is optional and is only present if there are uncommitted changes in the working directory.

Protocols (Consensus, Runtime Host, Runtime Committee)​

Oasis Core’s protocol versions use SemVer (semantic versioning) 2.0.0 with the following format:

MAJOR.MINOR.PATCH

where:

  • MAJOR represents the major version,
  • MINOR represents the minor version,
  • PATCH represents the patch version.

Whenever a backward-incompatible change is made to a protocol, the MAJOR version must be bumped.

If a new release adds a protocol functionality in a backwards compatible manner, the MINOR version must be bumped.

When only backwards compatible bug fixes are made to a protocol, the PATCH version should be bumped.

Version 1.0.0​

With the release of Oasis Core 20.10, we bumped the protocol versions to version 1.0.0 which signified that they are ready for production use.