...
Automated pre-release versions are released during the release cycle. During normal development time the releases will be marked with the suffix “-dev.X” (where X is a number) denoting a developmental release. Once EdgeX has entered a code freeze the automated releases will be tagged with the suffix “-rc.X” (where X is a number) to denote a release candidate. For components that have their own release cycles, the working group chair should decide when code freeze starts. When a component is ready for release, developers should inform the working group chairperson that manages the component. It will be up to the working group chairperson and the release manager to decide when to cut the release for the component. Once the release is cut the version will be updated to the next semantic version and the suffix will revert to “-dev.X” until the next code freeze.
The “next” semantic version can increase the major, minor or patch version of the component. If the TSC has already decided on the version number for the next named release (Ex: Delhi is 0.7 and Edinburgh is 1.0) the component should be set at that version. If the TSC has not decided on the version number for the next named release, then the working group chairperson and release manager can increase the patch version. It is recommended to wait until the TSC has decided the next version to release the component. However, for certain components that are released on their own release cycle (ie: SDKs) this may not be viable. For core releases during code freeze EdgeX will cut a release branch. For each repository, once the named release branch is cut then the master branch will be increased to the next forecasted version. From this point forward, the release branch will only be allowed to increase its patch version to not break the semantic versioning.
...
...
A repository has a branch cut for the Edinburgh release called “edinburgh”. The edinburgh branch will be version 1.0.0-rc.X and master will be 1.1.0-dev.X. This is because that master is now tracking development for the Fuji release. Similarly, the edinburgh branch is tracking release candidates for the Edinburgh release. Once the Edinburgh release is finalized the edinburgh branch will versioned at 1.0.0. The next version for edinburgh branch will be set to 1.0.1-dev.X to allow for any small patches like bug fixes or security patches.
Versioning and the Release Cycle
At the conclusion of each EdgeX release, the TSC meets and forecasts the version (major or minor) for the next release cycle. Based on the functionality to be implemented and included with the upcoming release, the EdgeX TSC may choose to preliminarily version the next release as a major release. If the next release will contain only backward compatible changes and deemed not to contain a significant amount of new and updated features, the TSC may choose to version the upcoming release as a minor version. For example, if the current release – codenamed "Portville" was a major version 7.0, the TSC may choose to set the next release to major version 8.0 (if they plan to include non-compatible changes or if the amount of new and updated functionality is significant enough to want to distinguish the release as a major release) or as a minor version 7.1 (indicating no changes that break compatibility with the prior named release).
All the VERSION files (on the current Master branch of the repositories) The semver file for the Main branch along with any other relevant indicators in the project repositories will immediately be updated to indicate this TSC decision.
Some event during the release cycle could dictate the TSC to change the version decision made at the start of a release. This could be from major to minor or from minor to major release. A decision to change the version strategy in the middle of the release cycle is not one that is done casually, should be avoided at all costs, and will cause a certain amount of hardship on the developers and confusion to users (example: development artifacts in repositories like Nexus or Docker would suddenly change and make it look like a new release was created). Below are some examples of when the TSC may change the version decision:
...