| Info | ||||||||
|---|---|---|---|---|---|---|---|---|
|
| Table of Contents |
|---|
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.
| Info | ||
|---|---|---|
| ||
SemVer.org follows a MAJOR.MINOR.PATCH scheme:
|
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.
| Info | ||
|---|---|---|
| ||
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:
|
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.
...
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.MARKETING.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.
...