High-Level Components
Common Functionality
Versioning
Oasis Core
1
YY.MINOR[.MICRO][-MODIFIER]
Copied!
where:
YYrepresents short year (e.g.19,20,21, ...),MINORrepresents the minor version starting with zero (e.g.0,1,2,3, ...),MICROrepresents (optional) final number in the version (sometimes referred to as the "patch" segment) (e.g.0,1,2,3, ...).If theMICROversion is0, it will be omitted.MODIFIERrepresents (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:1
gitCOMMIT_SHA[+dirty]
Copied!
where:
COMMIT_SHArepresents 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)
1
MAJOR.MINOR.PATCH
Copied!
where:
MAJORrepresents the major version,MINORrepresents the minor version,PATCHrepresents 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.
Last modified 28d ago