Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

If you would like, you could also bring up the issue on RocketChat for initial feedback before submitting the issue in GitHub Issues .

Versioning and Versioning Scheme



EdgeX has adopted a significance-based approach to versioning.  This versus a semantic versioning approach (see reference #1 below).

 

Instead of tightly coupling the version number updates to changes in the

REST API(s) exposed by a microservice, EdgeX updates the version

number when there has been a significance in the microservice

as a whole.

 

Similar to the semantic version scheme, the significance of change

scheme also uses a three-part version with numbers representing major,

minor, and patch changes.  The latter can be left off until actually needed.

 

A microservice starts its life as version 0.1, and each new release bumps

the second number.  The move from 0.x to 1.x in EdgeX signifies

that the microservice is transitioning from a development to a production

quality release.  The decision to make the transition to a production release rests with the responsible Working Group chair with approval from the EdgeX Technical Steering Committee.

 

Further jumps in the major number typically indicate major new releases

of the project which *could* signify API breakage, but could also

signify major new functionality as well.

 

If/when a maintenance release of a particular microservice is warranted,

a third number gets introduced.  So, if 0.5 is released, and a serious

bug is found and fixed immediately, 0.5.1 could be released right away,

while development continues as normal on master toward 0.6.

 

 

For example, you can see the historical version numbers used by the

bluez project (Linux Bluetooth stack) (see reference #2 below) are just major.minor, as they usually rely on distros to release maintenance releases.

 

An example of a project that uses three-digit versions is snapd (see reference #3 below), the daemon at the heart of the snap ecosystem.

 

[1] https://en.wikipedia.org/wiki/Software_versioning

 

[2] https://git.kernel.org/pub/scm/network/ofono/ofono.git/refs/tags

 

[3] https://github.com/snapcore/snapd/tags