...

The issue

The Opensource project ONAP uses a "global" version number like 9.0.0, 10.0.0, 11.0.0, 12.0.0, which applies to all components. This approach contradicts the cloud-native microservice concept and doesn't adhere to true Semantic Versioning (SemVer),  because the ONAP community uses only MAJOR to increase the Number for each Major release, like Jakarta for 9.0.0, Istanbul for 10.0.0, Kohn for 11.0.0 and London for 12.0.0. Minor is used one time for each release for a Maintenance release, like 9.1.0 with is Jakarta Maintenance release.

Our Goal:

We aim to adopt the Twelve-Factor App methodology that promotes semantic versioning and provides benefits of granular versioning, precise dependency management, and clearer communication for each major release.

...

1. Each ONAP component (microservice) will have its own individual SemVer version number that follows the SemVer specification: MAJOR.MINOR.PATCH. This will allow for granular versioning and precise dependency management for each component.

2. ONAP will use a marketing version number (e.g. "London" aka Version: 12) that will not be applied to the individual components. Rather, it will be a human curated decision to pick for each of the above listed components a version number and to guarantee with tests that that specific marketing release will work as defined by the tests.

This will provide a clear and consistent message for each major release.

An example of versions, similar to the Chrome version numbering:

• for Kohn (Marketing version 11 - every MAJOR component version number is completely independent from the Marketing number)
  • AAI: 27.4.5
  • SDC: 38.1.1
  • CDS: 44.69.0
  • Unmaintained Component: 6.69.1
  • Kafka: 7.1.2
  • Keycloak: 9.1.2
• for London (Marketing version 12)
  • AAI: 28.4.6
  • SDC: 43.2.1
  • CDS: 87.69.0
  • Unmaintained Component: 6.69.1
  • Kafka: 7.1.3
  • Keycloak: 9.1.3
• for Montreal (Marketing version 13)
  • AAI: 29.4.6
  • SDC: 43.2.1
  • CDS: 89.69.0
  • Unmaintained Component: 6.69.1
  • Kafka: 7.1.4
  • Keycloak: 9.1.4

Option 2: Use Marketing Version as MAJOR. MINOR and PATCH are completely in control of applications

1. Each ONAP component (microservice) will have a SemVer version number that follows the SemVer specification: MARKETING/MAJOR.MARKETING.MINOR.PATCH. 

2. ONAP will use a marketing version number (e.g. "London") as the MARKETING version number in the SemVer version number of each component.

   • The MARKETING/MAJOR

   version number

   • will represent the usual ONAP update cycle, e.g. 11 (Kohn), 12 (London), 13 (Montreal), marketing releases version number 

   • the MINOR will be used to represent incompatible API changes ,

   • the

   MARKETING

   • PATCH version number will represent

   MAJOR marketing releases, the MINOR version number will represent

   • new functionality in a backward-compatible manner

   , and the PATCH version

   • & number will represent backward-compatible bug fixes.

   ONAP will use a marketing version number (e.g. "London") as the MARKETING version number in the SemVer version number of each component.

This will allow the marketing version to be directly incorporated into the version number while still following the SemVer specification.

And basically everything is shifted one component to the "right" and from a traditional SemVer-Point-of-View.

An example of versions:

• for Kohn (Marketing version 11, and therefore all MAJOR numbers are 11 as well)
  • AAI: 11.4.5
  • SDC: 11.1.1
  • CDS: 11.69.0
  • Unmaintained Component: 11.69.1
  • Kafka: 7.1.2
  • Keycloak: 9.1.2
• for London (Marketing version 12, and therefore all MAJOR numbers are 12 as well)
  • AAI: 12.4.6
  • SDC: 12.2.1
  • CDS: 12.69.0
  • Unmaintained Component: 12.69.1
  • Kafka: 7.1.3
  • Keycloak: 9.1.3
• for Montreal (Marketing version 13, and therefore all MAJOR numbers are 13 as well)
  • AAI: 13.4.6
  • SDC: 13.2.1
  • CDS: 13.69.0
  • Unmaintained Component: 13.69.1
  • Kafka: 7.1.4
  • Keycloak: 9.1.4

Option 3: Leave it as it is

...