Adopt semantic version numbering for next release

[lucasgonze]

Problem

Semantic versioning is valuable to users in that it communicates the nature of each update. Magma version numbering has traditionally followed the numbering practice that predates widespread adoption of semantic versioning.

Along with usability benefits, semver helps with security by enabling reducing friction to adopting newer versions that may contain security improvements but also may create breakage. An that doesn't span a major version can be adopted more easily, allowing security patches to be picked up.

Solution

We should begin iterating version numbers according to how the content of an upgrade accords with semantic versioning.

Per https://semver.org/:

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes
    MINOR version when you add functionality in a backwards compatible manner
    PATCH version when you make backwards compatible bug fixes

We can implement this change without any retroactive impact. Our current latest version 1.8 implies a current semver of 1.8.0. The next version would be:

• 1.8.1 if it has only backward compatible bug fixes
• 1.9.0 if it adds functionality in a backwards-compatible manner
• 2.0.0 if it makes changes that are incompatible with 1.8

We are currently planning on a release to be labeled 1.9. As I understand the target set of changes, there is additional functionality to support 5G SA but no backwards-incompatible changes. Semver would suggest, therefore, that the next increment would be 1.9.0.

Non-goals

This change only affects labeling. It doesn't affect the content of releases.

This change would not affect previous releases.

This change would not be applied to the current release, except that we would give it an implicit semver of 1.8.0.

[lucasgonze]

The TSC has general consensus on the idea, but the details need to be worked out. Let's discuss in the next Features WG meeting, create a motion there, and bring the motion back to TSC.

[panyogesh]

@lucasgonze : Can you please have a look at the magma-versioning-link and see if addresses the requirement. If not we can discuss in next features-group call.

[lucasgonze]

@lucasgonze : Can you please have a look at the magma-versioning-link and see if addresses the requirement. If not we can discuss in next features-group call.

I am a little concerned that our definitions might be out of sync with the official version of semver. Let's have an in-depth conversation about what backwards compatibility means within the Magma architecture.

[lucasgonze]

Notes from TSC March 27:

Jordan comment: we are already using something like semantic versioning, but we need to document how we are constructing the numbers.

Yogesh will post a link to the definitions of versioning. Team can discuss in slack and follow up in Features WG.

[lucasgonze]

Probably stale, but let's consider re-activating.