...
This policy was updated with TSC approval on 6/25/19.
Table of Contents
Release Cycle / Cadence
The EdgeX Foundry community publishes new releases of EdgeX on 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:
...
Independent Tools and Services Release Cycle/Cadence
The following (in purple) is a proposed change to this section of the policy that is under consideration but not yet approved by the EdgeX TSC. The original section and current policy is in black under the purple proposal.
Some EdgeX services (and tooling) have a separate release cycle. The SDKs and services stemming from the SDKs, for example, are not necessarily released with the EdgeX release. Which services are allowed to have their own release cycles is at the discretion of the EdgeX Technical Steering Committee (TSC). Today, the following tools and services are released on independent release cycles:
- Device Service SDKs (Go and C)
- Device Services
- Application Functions SDK (Go)
- Application Services
When appropriate, a working group chairperson requests permission to release these tools and services. The release manager, at the request of the working group chairperson, is responsible for the release of these tools and services. Again, these tools and services are versioned by semantic versioning just as the rest of EdgeX to indicate what is included with the release (and specifically whether it includes compatible or non-compatible features and APIs). Disagreements with a release manager decision about when to release is adjudicated by the TSC.
SDKs and Associated Services Major Releases
SDKs (Device or Application Functions) release major versions that coincide with the major release of EdgeX. To reiterate a major release is one that contains non-backward compatible changes. The major versions of SDKs, for example, are tightly coupled to the major version of EdgeX. At this time, the major versions of EdgeX and the SDKs will be the same (i.e. 1.x of the SDK works with 1.x of EdgeX, and 2.x of the SDK works with 2.x of EdgeX). It is the goal of the project that major releases of the SDKs generally release at or near the same time (within months) as the EdgeX major releases.
Services created from the SDKs - for example, Device and Application Services - are versioned from the SDK. Thus, major versions of the device and application services must be built/rebuilt when a new major release of the SDK is created.
SDKs and Associated Services Minor Releases/Patches
SDKs (Device or Application Functions) can release minor versions or patches completely independently of the EdgeX release (and vice versa – minor releases of the rest of EdgeX can occur independently of SDK minor releases). A minor version or patch is backward compatible (with regard to APIs, configuration, etc.) with the existing major version of the SDK. For example, after 2.0 major release of EdgeX and the Device Service SDK, the SDK may choose to release versions 2.0.1, 2.0.2, 2.1.0, 2.2.0 and 2.2.1 while the rest of EdgeX is still at version 2.0. All of these minor releases would still be compatible with EdgeX 2.0.
Conversely, EdgeX may have a 2.1 minor release, and this would not impact the Device Service SDK. Any 2.x version of the SDK would still work with any version of EdgeX 2.x.
Device and Application Services are again versioned from the SDK. Thus, device and application services with a minor release version (for example 2.0.1 or 3.1.0) indicates the device or application service was built from the associated SDK version (in this case 2.0.1 and 3.1.0 respectively).
Some EdgeX services (and tooling) have a separate release cycle. The Device Service SDKs, Device Services, Application Services and Application Functions SDK, for example, are not necessarily released with the EdgeX release. Which services are allowed to have their own release cycles is at the discretion of the EdgeX Technical Steering Committee (TSC). Services or tools that have their own release cycle may choose to release at the same time as the EdgeX release (the code named release) but are not required to and the version of these services or tools may not be the same as the versions of the services and tools associated to the EdgeX release. Today, the following tools and services are released on independent release cycles:
Device Service SDKs (Go and C)
Device Services
Application Functions SDK (Go)
Application Services
When appropriate, a working group chairperson requests permission to release these tools and services. The release manager, at the request of the working group chairperson, are responsible for the release of these tools and services. Again these independent tools and services are versioned by semantic versioning to indicate what is included with the release (and specifically whether it includes compatible or non-compatible features and APIs). Disagreements with a release manager decision about when to release is adjudicated by the TSC.
While the release cycle for these independent services varies from the EdgeX release, the rules on major, minor, and patch releases and versioning (as discussed below) still apply. As an example, the SDK decides to release 1.0 with Edinburgh. There are no other changes to the SDK for two years. SDK remains 1.0 during that period. After 2 years, when EdgeX “Indiana” is released at version 5.0, the SDK decides to also make a minor version release. They release 1.1 under semantic versioning rules (backward compatible, etc). The SDK (and DS) are separate from EdgeX release and therefore the versions may not coincide. They can elect to release and version at the same time as EdgeX release, but they are not part of EdgeX release by definition.
...