OOM-3079 - Getting issue details... STATUS

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.

SemVer

SemVer.org follows a MAJOR.MINOR.PATCH scheme:

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

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.

12 factor

The Twelve-Factor App methodology is a set of best practices for building modern, cloud-native applications that are scalable, maintainable, and resilient. One of the key principles of the Twelve-Factor App methodology is the use of a version control system to manage the codebase and the application's configuration.

From https://12factor.net/ it states:

Use Semantic Versioning: Twelve-Factor Apps use semantic versioning (SemVer) to version their releases. SemVer specifies a MAJOR.MINOR.PATCH versioning scheme, where a MAJOR version is for incompatible API changes, a MINOR version is for new functionality in a backward-compatible manner, and a PATCH version is for backward-compatible bug fixes.

Possible Solutions:

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.
Include Marketing Version in SemVer: Each ONAP component will have a SemVer version number that includes the marketing version number.
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

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

Each ONAP component (microservice) will have a SemVer version number that follows the SemVer specification: MARKETING/MAJOR.MINOR.PATCH.
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