Re: Proposal for new release versioning scheme for EdgeX



Trevor Conn
Technical Staff Engineer
Core Working Group Chair of EdgeX Foundry
Dell Technologies | IoT DellTech
Round Rock, TX  USA

From: EdgeX-TSC@... <EdgeX-TSC@...> on behalf of Joe Pearson <joe.pearson@...>
Sent: Thursday, June 20, 2019 3:48 PM
To: EdgeX-TSC@...
Subject: Re: [Edgex-tsc] Proposal for new release versioning scheme for EdgeX



Joseph "Joe" Pearson

Technology Strategist

IBM Cloud

1 770 626 0433 Office


----- Original message -----
From: "Ike Alisson" <ike.alisson@...>
Sent by: EdgeX-TSC@...
To: "Gregg, James R" <james.r.gregg@...>
Cc: "EdgeX-TSC@..." <EdgeX-TSC@...>, "Rashidi-ranjbar, Lisa A" <lisa.a.rashidi-ranjbar@...>
Subject: [EXTERNAL] Re: [Edgex-tsc] Proposal for new release versioning scheme for EdgeX
Date: Thu, Jun 20, 2019 1:31 PM
Ike Alısson
GSM :                +46 707 60 99 00
E-mail:               ike.alisson@...
This communication is confidential and intended solely for the addressee(s). Any unauthorized review; use, disclosure, or distribution is prohibited.  If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it.  Thank you.  E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
Den tors 20 juni 2019 kl 19:15 skrev Gregg, James R <james.r.gregg@...>:

TSC Members,

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 here.



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.


Major, 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.

Pre-release Versions and the Release Cycle

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.

For example:

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.



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.



Thank you.


James Gregg

IOTG RBHE DevOps | EdgeX Foundry DevOps

Email: james.r.gregg@...

Tel: (480) 552-7965






Join to automatically receive all group messages.