...

To address the Snapshot dependency scenario, the idea is to move away from Snapshot dependency to "Release Artifact" dependency only. The word "Release Artifact" is loaded with the sense that the build is stable, has been thoroughly tested and can be used by another team. The "Released Artifact" is available within the "Nexus Release"  stage  repo (refer to Nexus section below for further description of Nexus stagesrepos). The PTLs and the project team decide on their own when to create a "Release Artifact". This approach allows to truly decouple the builds from each other and avoid the situation where something that was working fine before doesn't suddenly break due to snapshot changes.

...

ONAP is composed of more than 30 projects and 200 repositories. Dealing with components dependencies and documenting the version tree for each build can become a Dantesque activity.

In order to know whether you're depending on the right version of a particular artifact, ONAP will be maintaining a master "version manifest" for each named release (e.g. Amsterdam) specifying that the version of each component that is to be delivered with that within a release.  The manifest is a structured list of components and their versions. The manifest is intended to track a particular ONAP release and be used to track all versions of all components within a release. 

...

Due to the change of the cpt A version in o-parent, o-parent itself needs to be bumped to 0.9.1.  Now we have a circular dependency.

Each project teams PTLs will need to update the manifest to declare the "Released" version available.  In order to avoid the circular dependency issue, any updates to the version manifest, in and or itself, must NOT require any artifact to be version bumped and re-released.  

Understanding the above, ONAP is maintaining a manifest of "Released Artifacts" outside the build process and outside of any binary artifacts.  However, the manifest is still in source control. A specific version of this manifest will be blessed by TSC and used to make the "Named Release" (see definition of "Named Release" below).

Nexus

ONAP is using Nexus in 3 stages3 types of Nexus repos:

1. Snapshot repo: used for merged artifacts. After the committer has performed the code review (+2), has merged the code and the build is successful, the build artifact are is within the Snapshot repo. It is expected to have multiple snapshot snapshots for a single repo per day. All artifacts have same version number. The artifact triggers CSIT testing.
2. Staging repo: used for Release candidate. Once a day, a new clean build is automatically performed. All artifacts have same version number. The Staging artifact is used for the E2E Release testing.
3. Release repo: this is the place where the project team (or Linux Fondation Releng Team) stores the artifacts that are deemed stabled for being consumed by the other project teams. Each team decides when to release. It is not expected to get a new release every day. No TSC approval is required for getting a new release artifact.

...

Each project team decides on when version numbers of repos under it’s control are incremented and artifacts are place in a Nexus release repositoryRelease repo. 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 has 2 levels types of artifacts:

1. Artifact Release: this refers to all the jar and docker files that are under the control of a project. No TSC approval is necessary for the team to move artifacts within Nexus Release
2. Named Release: this refers to the Marketing name that is used externally to evangelize ONAP. The "Named Release" is a collection of properly versioned "Artifact Release". The "Named Release" required TSC approval and is published within Docker Hub.

...

1.1.0-Amsterdam is an Enhancement Release and is released to deliver (for example) a backward compatioble compatible functionality in "AAF cpt 1" and "AAF cpt 2" components. Note the second digits are now "1" and "7". Note also there is no version continuity in "AAF cpt 2" between the Service (4) and the Enhancement (7) Releases. This is acceptable as the team may have delivered intermediate "Artifact Release" that were not embedded with a "Named Release".

...

More details at: http://semver.org 

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

...

...

Docker Containers

...

Branching and Merging

Basic Principles

...