Today in the DevOps meeting, Lisa Rashidi-Ranjbar (Release Czar) outlined a proposal for a new pre-release versioning scheme that will help with future build automation and release management. As reviewed in the EdgeX DevOps WG
call this morning, the proposal was well received by everyone and we would like to quickly adopt the new versioning scheme so that we can move forward and unblock some current issues which are impacting our Jenkins build automation.
At a high level, the new proposal differentiates between branches that are tagged with a suffix that clearly defines the different modes - development (-dev.X) and release candidate (-rc.X).
I’m seeking approval from TSC members to formally adopt this new release versioning scheme as outlined by Lisa.
For reference, please review the presentation
In addition to this proposal, the following verbiage is now put forth for review and approval from the TSC members.
The following are the wiki page changes that outline the full details of the proposal.
Minor Versions, Patches and Pre-release Versions
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.
EdgeX has automated pre-release versions with suffixes to speed up integration and testing between the different components. These suffixes are, “dev.X” (where X
is a number) to denote a developmental release and “rc.X” to denote a release candidate.
Versions and the Release Cycle
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.
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.
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.
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.
Please review and provide input along with +1 for approval / adoption of the new
pre-release versioning process. Thank you Lisa for formalizing the proposal and putting it forth today for consideration.
IOTG RBHE DevOps
| EdgeX Foundry DevOps