...
The EdgeX Foundry community publishes new releases of EdgeX serviceson a regular cadence, enabling the community, businesses and developers to plan their roadmaps with certainty of access to new features.
Releases of the collection of central or core EdgeX micro services get a development codename (example: ‘Edinburgh’). EdgeX micro services that are part of this collection include:
...
For the purposes of the rest of this document, the term “EdgeX release” refers to the release of this collection of central EdgeX micro services. The EdgeX release code name is sequential in that the code names are alphabetical. The Edinburgh release is before the Fuji release, which is before Geneva release, etc. The EdgeX release code names are based on geographical locations. These releases also get a version number. For example, the Delhi release was version 0.7. EdgeX releases the collection of central or core EdgeX micro services twice a year (typically around April and October). Additionally, all microservices in the central EdgeX collection (listed above) have the same version number corresponding to that release. For example, both the Core Data microservice and Core Metadata microservice for the Delhi 0.7 release will have version numbers of 0.7. For a patch release (explained below) such as 0.7.1, all of the microservices have the same version number 0.7.1.
EdgeX's versioning scheme is based on semantic versioning (https://semver.org/). However, the project may, at times, decide to release a major version due to significance-based changes or marketing decision.
The EdgeX codenamed release should not be confused with MAJOR version! Per semantic versioning definition, a MAJOR version is typically a significant milestone in the product that includes key features or updates and may include non-backward compatible changes (features, APIs, etc). Not all of the EdgeX codenamed releases completed each six months will be “significant” or contain “non-backward compatible changes”. See major, minor and patch version information below.
Note, it is not determined whether the new Application Services will be part of the EdgeX release or live as independent tools and services (as defined below). TSC decision is pending.
Independent Tools and Services Release Cycle/Cadence
...
All services will have a “ping” API that will respond with the version number. This allows independent services and tooling (listed in the previous section) to query other EdgeX services that it works with and check for compatibility. For example, when a Device Service built to work with EdgeX 1.0 comes up and it queries Core Data via the ping API and gets a response of 2.0, the device service can choose to log the issue (providing a clear indication of a version mistach) and exit. The query calling service determines whether it is compatible or not (exiting or continuing). Each services only offers a query API that indicates what version of EdgeX it is.
Major, Minor Versions and Patches
Again, EdgeX follows semantic versioning. Major releases have a “major number” or version number like 1.0, 2.0, etc. Major releases will typically include significant new features, new or significantly updated services, new or significantly updated APIs, etc. and may be incompatible with previous releases (major or minor). Minor releases may contain some new or updated functionality but should always be backward compatible with the associated Major and Minor releases it is based on. Minor releases have a version number which includes a Major release number, a decimal, and a minor release number (like 1.1, 2.1, 2.3, etc.). Patches (or Patch releases) are releases that contain backward compatible bug fixes. Patches should not contain any new or updated features except those necessary to address the bug(s). Patch versions are based on a major version number, a minor version number (or zero if the patch is to the original major version, and a patch version (like 1.0.1, 1.2.1, 2.1.1, etc.) with decimals between these numbers.
Versioning and the Release Cycle
...