PROPOSED draft to be reviewed and approved by the TSC. Not official or final yet. This policy will be used to govern EdgeX Edinburgh release and all following releases.
...
Document editors - highlight changes and fictes fixes.
...
Release Cycle / Cadence
The EdgeX Foundry community publishes new releases of EdgeX services on a regular cadence, enabling the community, businesses and developers to plan their roadmaps with certainty of access to new features.
...
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
...
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.
Major, Minor Versions and Patches
...
Decisions about patches (versions made between the release cycle that are used for for backwards-compatible bug fixes) are at the discretion of the release manager for that release cycle. A work group chairperson can make the request for a patch release, but the decision lies with the release manager. Disagreement can be appealed to the full TSC for adjudication. The release manager must coordinate the patch release with all applicable working groups (via the chairman) - thus the reason a working group chairperson is not unilaterally allowed to produce a release.
This next section is still under review by DevOps and LF for impact to CI/CD and other operations.
The release manager can coordinate "pre-release" versions of the artifacts in the middle of the release cycle. These artifacts are used by the developer and user community to demonstrate and test upcoming release functionality and changes. These artifacts use a version string containing a hyphen followed by an arbitrary string (like -dev, -test, -{timestamp}, etc.) to distinguish them from the final release of that version (see paragraph 9 of the semantic versioning specification for more background).