You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

ONAP Versioning Strategy

Objective

The goal of the ONAP versioning strategy is to provide a compromise addressing the following competing goals:

  • Minimize work and complexity for project teams
  • Provide an easy to use configuration to ONAP users and the integration team
  • Be intuitive

Scope

The version strategy handles version selection of ONAP artifacts such as repos and containers as well as cross component APIs.

Version Selection

All versioning uses a semantic versioning approach. In particular:

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, and
  • PATCH version when you make backwards-compatible bug fixes.

More details at: http://semver.org

Versioning of Repos

Each project will decide on when version numbers of repos under it’s control are incremented and artifacts are place in a release branch. In particular the version numbers do not have to be in sync across projects and do not have to be aligned with the release version number.

ONAP Release Versioning

The O-Parent file tracks the version of all ONAP artifacts. All projects with dependencies to other repos are required to use the version exposed in the O-Parent file to reference the other repos.

The O-Parent file in the master branch will track the repo versions currently tested in integration testing.

The O-Parent file is aligned with the ONAP Release timing and versioning.  The O-Parent file in the release branch will reference all the repo versions included in the release.

Docker Containers

Docker containers are assembled as required. The versioning of the docker containers matches the versioning of the O-Parent file used to build them.

API Versioning

This requires some more thought. Questions to answer:


  • Who assigns version numbers?
  • same as for repos. Projects decide
  • Where do we track available APIs for a given release ?
  • -> we need something that has a similar role to O-Parent
  • What’s our policy of depreciating APIs? 
  • -> I assume we would require MAJOR API versions to be available for extended periods of time


  • No labels