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.

Challenges:

The ONAP community is yet to understand a workflow that assigns an individual SemVer version number to each component, while also maintaining a marketing version number like "London" for version 12.x.x.

Possible Solutions:

1. Separate Marketing-Version and Component Version: Each ONAP component will have a individual/distinct SemVer number. A marketing version number, like "London" for Version: 12, will not be applied to individual components.

2. Include Marketing Version in SemVer: Each ONAP component will have a SemVer version number that includes the marketing version number.

3. Maintain Current System: Leave the current version numbering schema unchanged.

Examples: Kubernetes and Istio Service Mesh have successfully implemented hybrid versioning schemes.

Benefits and Drawbacks: While this approach enhances granular versioning and clearer communication, it could be more complex to implement than a global version number.

More thoughts - Technical Proposal how to implement it:

Option 1: Completely separate "Marketing-Version" and component version

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.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 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 PATCH version number will represent new functionality in a backward-compatible manner & number will represent backward-compatible bug fixes.

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

#NeverChangeAWorkingVersionNumberingSchema

Next Steps: We need to decide on the best versioning approach and address the "common/common" issue.

Problems to solve - Dependency to "common" templates/charts

OOM provides charts for common use to ease and harmonize the resulting helmcharts.

These charts are located under https://git.onap.org/oom/tree/kubernetes/common

List of important ones:

• common → templates
• cassandra → DB cluster deployment
• dgbuilder → directedGraph (only used by SDNC) 
• elasticsearch → DB cluster deployment
• etcd → DB cluster deployment
• etcd-init → DB creation jobs
• mariadb-galera → DB cluster deployment
• mariadb-init → DB creation jobs
• mongo → DB cluster deployment
• network-name-gen → tool (only used in SDNC)
• postgres → DB cluster deployment
• postgres-init → DB creation jobs
• readinessCheck → common tool
• repositoryGenerator → common tool for common repository overrides
• serviceAccount → tool to create RBAC setup
• timescaleDB → DB cluster deployment

Question to solve:

• Chart versioning and dependency management